Počítačové viry - analýza útoku a obrana

E N C Y K L O P E D I E

Z O N E R

P R E S S

Poč očítačové ítačové viry analýza útoku a obrana

• Analýza škodlivého kódu • Klasifikace metod infekce obranné strategie • Základní virů techniky vývoje • Pokročilé kódu • Techniky antivirové obrany paměti • Skenování a dezinfekce obrany na síťové • Strategie úrovni • Způsoby blokování červů

© Foto: Jiří Heller

P e t e r

S z o r

Počítačové viry analýza útoku a obrana

Peter Szor

Art of Computer Virus Research and Defense by Peter Szor.

Authorized translation from the English language edition, entitled ART OF COMPUTER VIRUS RESEARCH AND DEFENSE, THE, 1st Edition, 0321304543, by SZOR, PETER, published by Pearson Education, Inc, publishing as Addison Wesley Professional, Copyright © 2005 by Symatec Corporation.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. CZECH language edition published by ZONER SOFTWARE, s.r.o., Copyright © 2006.

Autorizovaný překlad anglického vydání nazvaného ART OF COMPUTER VIRUS RESEARCH AND DEFENSE, první vydání, 0321304543, autor SZOR, PETER, vydal Pearson Education, Inc. ve vydavatelství Addison Wesley Professional, Copyright © 2005 Symatec Corporation.

Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována nebo předávána žádnou formou nebo způsobem, elektronicky ani mechanicky, včetně fotokopií, natáčení ani žádnými jinými systémy pro ukládání bez výslovného svolení Pearson Education, Inc. České vydání vydal ZONER SOFTWARE, s.r.o., Copyright © 2006.

Tato publikace vznikla jako výsledek řešení projektu Zoner AntiVirus, kterého výzkum a vývoj je finančně podporován Ministerstvem průmyslu a obchodu ČR v rámci programu IMPULS.

Počítačové viry – analýza útoku a obrana Autor: Peter Szor Copyright © ZONER software s.r.o. Vydání první v roce 2010. Všechna práva vyhrazena.

Zoner Press ZONER software s.r.o.

Nové sady 18, 602 00 Brno Překlad: Ing. Lukáš Pelikán, Ing. Roman Skřivánek Odpovědný redaktor: Miroslav Kučera Šéfredaktor: Ing. Pavel Kristián DTP: Miroslav Kučera © Cover foto: Jiří Heller, HELLER.CZ s.r.o, www.heller.cz © Cover: PYRAMIDE, s.r.o.

Informace, které jsou v této knize zveřejněny, mohou byt chráněny jako patent. Jména produktů byla uvedena bez záruky jejich volného použití. Při tvorbě textů a vyobrazení bylo sice postupováno s maximální péčí, ale přesto nelze zcela vyloučit možnost výskytu chyb. Vydavatelé a autoři nepřebírají právní odpovědnost ani žádnou jinou záruku za použití chybných údajů a z toho vyplývajících důsledků. Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována ani distribuována žádným způsobem ani prostředkem, ani reprodukována v databázi či na jiném záznamovém prostředku či v jiném systému bez výslovného svolení vydavatele, s výjimkou zveřejnění krátkých částí textu pro potřeby recenzí.

Veškeré dotazy týkající se distribuce směřujte na: Zoner Press ZONER software s.r.o.

Nové sady 18, 602 00 Brno tel.: 532 190 883, fax: 543 257 245 e-mail: knihy@zoner.cz http://www.zonerpress.cz

ISBN 978-80-7413-081-6

Vฤ novรกno Natรกlii

5

Obsah O autorovi Předmluva Poděkování

18 19 21

Část I – Strategie útočníka Kapitola 1

Úvod do her přírody

1.1 Rané modely sebereplikujících struktur 1.1.1 John von Neumann: Teorie automatů schopných vlastní reprodukce 1.1.2 Fredkin: Reprodukční struktury 1.1.3 Conway: Hra života 1.1.4 Války o jádro: bojující programy 1.2 Geneze počítačových virů 1.3 Automaticky se replikující kód: teorie a definice počítačových virů Odkazy

Kapitola 2

Fascinující analýza škodlivého kódu

2.1 Obvyklé vzorce výzkumu v oblasti virů 2.2 Vývoj antivirové obrany 2.3 Terminologie škodlivých programů 2.3.1 Viry 2.3.2 Počítačoví červi 2.3.3 Logické bomby 2.3.4 Trojští koně 2.3.5 Zárodky 2.3.6 Exploity 2.3.7 Stahovače 2.3.8 Dialery 2.3.9 Droppery 2.3.10 Injektory 2.3.11 Auto-Rootery 2.3.12 Kity (generátory virů) 2.3.13 Programy pro spam 2.3.14 Floodery

25 26 27 28 29 33 37 38 40

41 43 44 45 45 45 46 47 48 48 49 49 49 49 50 50 50 51

6 2.3.15 Snímače stisku kláves 2.3.16 Rootkity 2.4 Další kategorie 2.4.1 Zábavné programy 2.4.2 Poplašné zprávy: řetězové dopisy 2.4.3 Další hmyz: adware a spyware 2.5 Schéma pojmenování počítačových škodlivých programů 2.5.1 <jméno_rodiny> 2.5.2 <typ_škodlivého_programu>:// 2.5.3 <platforma>/ 2.5.4 <jméno_skupiny> 2.5.5 <infekční_délka> 2.5.6 <varianta> 2.5.7 [<<převod >] 2.5.8 <modifikátory> 2.5.9 :<specifikátor_lokace> 2.5.10 #<způsob_komprimace> 2.5.11 @m nebo @mm 2.5.12 !<výrobce_speciální komentář > 2.6 Komentovaný seznam oficiálně rozpoznávaných platforem Odkazy

Kapitola 3

Prostředí škodlivého kódu

3.1 Závislost na počítačové architektuře 3.2 Závislost na procesoru 3.3 Závislost na operačním systému 3.4 Závislost na verzi operačního systému 3.5 Závislost na souborovém systému 3.5.1 Cluster viry 3.5.2 Viry pro NTFS Stream 3.5.3 Viry využívající kompresi NTFS 3.5.4 Infekce ISO obrazů 3.6 Závislost na formátu souboru 3.6.1 COM viry v prostředí DOSu 3.6.2 EXE viry v prostředí DOSu 3.6.3 NE (New Executable) viry pro 16bitová Windows a OS/2 3.6.4 LX viry na OS/2 3.6.5 Viry napadající soubory PE prostředí 32bitových Windows

51 51 51 51 52 52 53 54 54 54 55 55 55 55 55 55 56 56 56 56 60

61 63 64 65 66 66 66 68 68 69 69 69 69 69 70 70

7 3.6.6 Viry infikující soubory ELF v prostředí systému UNIX 3.6.7 Viry napadající ovladače zařízení 3.6.8 Viry infikující objekty a LIB 3.7 Závislost na překladači 3.7.1 Makro viry v produktech firmy Microsoft 3.7.2 REXX viry na systémech IBM 3.7.3 DCL viry na DEC/VMS 3.7.4 Shell skripty na UNIXu (csh, ksh a bash) 3.7.5 VBScript viry na systémech Windows 3.7.6 Dávkové viry 3.7.7 Viry ve skriptech programů mIRC, PIRCH 3.7.8 SuperLogo Viry 3.7.9 JScriptové viry 3.7.10 Perlovské viry 3.7.11 Červi WebTV napsaní v JellyScriptu a vložení do HTML e-mailů 3.7.12 Viry pro Python 3.7.13 VIM viry 3.7.14 EMACS viry 3.7.15 TCL viry 3.7.16 PHP viry 3.7.17 MapInfo viry 3.7.18 ABAP viry na SAPu 3.7.19 Viry pro soubory nápovědy Windows – když zmáčknete F1...

3.7.20 JScriptové hrozby v souborech Adobe PDF 3.7.21 Závislost na AppleScript 3.7.22 Závislost na ANSI 3.7.23 Hrozby v ActionScriptu 3.7.24 Hrozby skriptů HyperTalk 3.7.25 Skriptovací viry pro AutoLisp 3.7.26 Závislost na registru 3.7.27 Závislost na PIF a LNK 3.7.28 Makro viry programu Lotus Word Pro 3.7.29 Viry dokumentů AmiPro 3.7.30 Viry pro Corel Script 3.7.31 Závislost na makrech produktů Lotus 1-2-3 3.7.32 Závislost na instalačních skriptech systému Windows 3.7.33 Závislost na AUTORUN.INF a souborech INI systému Windows 3.7.34 Závislost na HTML (Hypertext Markup Language)

73 73 74 75 75 84 85 86 87 87 88 88 90 91 91 91 92 92 92 92 93 93 93 94 94 94 95 95 96 97 97 98 98 98 99 99 99 100

8 3.8 Závislost na zranitelnosti 3.9 Závislost na času a datu 3.10 JIT závislost – viry Microsoft .NET 3.11 Závislost na archivovaných formátech 3.12 Závislost na příponě souboru 3.13 Závislost na síťovém protokolu 3.14 Závislost na zdrojových kódech 3.14.1 Zdrojové kódy trojských koní 3.15 Závislosti na zdrojích v platformách Mac a Palm 3.16 Závislost na velikosti hostitele 3.17 Závislost na debbuggerech 3.17.1 Zamýšlené hrozby spoléhající na debugger 3.18 Závislost na kompilátoru a linkeru 3.19 Závislost na vrstvě překladači zařízení 3.20 Závislost na vkládaných objektech 3.21 Závislost na vlastním prostředí 3.22 Multipartitní viry 3.23 Závěr Odkazy

Kapitola 4

Klasifikace metod infekce

4.1 Boot viry 4.1.1 Techniky infekce Master Boot Recordu (MBR) 4.1.2 Techniky infekce DOS BOOT Recordu (DBR 4.1.3 Boot viry, které dovedou pracovat s Windows 95 4.1.4 Možné útoky boot virů v síťovém prostředí 4.2 Techniky infekce souborů 4.2.1 Přepisující viry 4.2.2 Náhodně přepisující viry 4.2.3 Připojující viry 4.2.4 Viry připojující se na začátek souboru 4.2.5 Klasické parazitické viry 4.2.6 Dutinové viry 4.2.7 Dělené dutinové viry 4.2.8 Komprimující viry 4.2.9 Infekce typu Amoeba 4.2.10 Technika přidání decryptoru 4.2.11 Technika vložení decryptoru a virového těla

100 101 101 102 103 104 104 105 106 107 107 108 109 109 111 112 114 115 115

119 120 121 123 125 125 126 126 128 128 129 131 132 133 134 134 135 136

9 4.2.12 Technika matoucího odskoku 4.2.13 Technika utajení vstupního bodu (EPO) 4.2.14 Možné budoucí techniky infekce: stavitelé kódu 4.3 Důkladný pohled na Win32 viry 4.3.1 Win32 API a platformy, které je podporují 4.3.2 Techniky infekce na 32bitových Windows 4.3.3 Win32 a Win64 viry: navržené pro Microsoft Windows?

4.4 Závěr Odkazy

Kapitola 5

137 139 148 149 150 152 168 170 170

Klasifikace metod infekce paměti

173

5.1 Viry přímé akce 5.2 Paměťově rezidentní viry 5.2.1 Obsluha a zavěšování na přerušení 5.2.2 Závěsné rutiny na INT 13h (boot viry) 5.2.3 Závěsné rutiny na INT 21h (souborové viry) 5.2.4 Obvyklé techniky instalace do paměti pod DOSem 5.2.5 Stealth viry 5.2.6 Infekce diskové cache a systémového bufferu 5.3 Dočasné paměťové rezidentní viry 5.4 Swapovací viry 5.5 Viry v procesech (v uživatelském režimu) 5.6 Viry v režimu jádra (Windows 9x/Me) 5.7 Viry v režimu jádra (Windows NT/2000/XP) 5.8 Viry vkládající se do paměti přes síť Odkazy

174 174 175 179 180 183 185 194 195 196 196 197 197 199 200

Kapitola 6

Základní obranné strategie virů

6.1 Tunelující viry 6.1.1 Skenování v paměti původní obsluhy 6.1.2 Trasování s pomocí ladících rozhraní 6.1.3 Tunelování na bázi emulace kódu 6.1.4 Přístup k disku přes I/O porty 6.1.5 Použití nedokumentovaných funkcí 6.2 Obrněné viry 6.2.1 Obrana proti disassemblování 6.2.2 Zakódovaná data

201 202 202 202 203 203 203 203 204 204

10 6.2.3 Matení kódu pro znesnadnění analýzy 6.2.4 Matení kódu založené na míchání operačních kódů 6.2.5 Používání kontrolních součtů 6.2.6 Komprimovaný matoucí kód 6.2.7 Obrana proti ladění 6.2.8 Obrana proti heuristické analýze 6.2.9 Obrana proti emulaci 6.2.10 Viry vyhýbající se návnadám 6.3 Agresivní retroviry Odkazy

Kapitola 7 Pokročilé techniky vývoje kódu a generátory počítačových virů 7.1 Úvod 7.2 Vývoj virového kódu 7.3 Zakódované viry 7.4 Oligomorfní viry 7.5 Polymorfní viry 7.5.1 Virus 1260 7.5.2 Dark Avengerův mutovací engine (MtE) 7.5.3 32bitové polymorfní viry 7.6 Metamorfní viry 7.6.1 Co je metamorfní virus?

7.6.2 Jednoduché metamorfní viry 7.6.3 Složitější metamorfní viry a permutační techniky 7.6.4 Mutování dalších aplikací: definitivní generátor virů?

7.6.5 Pokročilé metamorfní viry: Zmist 7.6.6 {W32,Linux}/Simile: metamorfní engine napříč systémy 7.6.7 Temná budoucnost – metamorfní MSIL viry 7.7 Generátory počítačových virů 7.7.1 VCS (Virus Construction Set) 7.7.2 GenVir 7.7.3 VCL (Virus Creation Laboratory) 7.7.4 PS-MPC (Phalcon-Skism Mass-Produced Code Generator) 7.7.5 NGVCK (Next Generation Virus Creation Kit) 7.7.6 Další nástroje a mutační enginy 7.7.7 Jak testovat generátory počítačových virů?

Odkazy

205 206 207 207 208 215 222 225 226 228

229 230 230 231 235 237 237 238 240 244 245 246 247 250 251 254 258 260 260 260 261 261 262 262 263 264

11 Kapitola 8

Klasifikace podle payloadu

8.1 Bez payloadu 8.2 Náhodně destruktivní payload 8.3 Nedestruktivní payload 8.4 Příležitostně destruktivní payload 8.5 Velmi destruktivní payload 8.5.1 Viry přepisující data 8.5.2 Data Diddlers 8.5.3 Viry šifrující data: dobří, zlí a oškliví 8.5.4 Ničení hardware 8.6 Útoky DoS – odmítnutí služby 8.7 Získávání peněz pomocí virů 8.7.1 Phishing 8.7.2 Vlastnosti zadních vrátek 8.8 Závěr Odkazy

Kapitola 9

Strategie počítačových červů

9.1 Úvod 9.2 Generická struktura počítačových červů 9.2.1 Vyhledávač obětí 9.2.2 Modul pro šíření infekce 9.2.3 Vzdálené ovládání a rozhraní pro aktualizaci 9.2.4 Plánovač životního cyklu 9.2.5 Payload 9.2.6 Sledování počtu infikovaných systémů 9.3 Vyhledávač obětí 9.3.1 Sklízení e-mailových adres 9.3.2 Útoky založené na prohledávání sdílených prostředků 9.3.3 Skenování sítě a označení cíle 9.4 Šíření infekce 9.4.1 Útok na systémy kompromitované pomocí zadních vrátek 9.4.2 Útoky na peer-to-peer sítě 9.4.3 Útoky pomocí systémů pro okamžitý přenos zpráv 9.4.4 Útoky pomocí e-mailů a klamavých technik 9.4.5 Útoky pomocí přímého vkládání e-mailů do schránky 9.4.6 Útoky založené na SMTP Proxy

265 266 267 267 269 270 270 271 272 273 274 276 276 276 278 279

281 282 283 283 283 283 284 285 286 286 286 290 291 295 296 297 297 298 298 299

12 9.4.7 Útoky přes SMTP 9.4.8 Použití MX dotazů pro zrychlené šíření pomocí SMTP 9.4.9 Útoky pomocí NNTP (Network News Transfer Protocol) 9.5 Běžný kód červa a spouštěcí techniky 9.5.1 Útoky založené na spustitelném kódu 9.5.2 Odkazy na webové stránky nebo webové proxy 9.5.3 E-mail založený na HTML kódu 9.5.4 Útoky založené na vzdáleném přihlašování 9.5.5 Útoky injektáží kódu 9.5.6 Útoky založené na interpretech příkazů 9.6 Aktualizační strategie počítačových červů 9.6.1 Autentizované aktualizace z webu 9.6.2 Aktualizace založené na zadních vrátkách 9.7 Vzdálené ovládání pomocí signalizace 9.7.1 Kontrola nad Peer-to-Peer sítěmi 9.8 Úmyslné a náhodné interakce 9.8.1 Spolupráce 9.8.2 Soutěžení 9.8.3 Budoucnost – jednoduchý komunikační protokol pro červy?

9.9 Červi pro bezdrátová mobilní zařízení Odkazy

Kapitola 10 Exploity, zranitelná místa, útoky založené na přetečení bufferu 10.1 Úvod 10.1.1 Definice smíšeného útoku 10.1.2 Hrozba 10.2 Pozadí 10.3 Typy zranitelností 10.3.1 Přetečení bufferu 10.3.2 První generace útoků 10.3.3 Útoky druhé generace 10.3.4 Útoky třetí generace 10.4 Současné a dřívější hrozby 10.4.1 Internetový červ Morris, 1988(přetečení bufferu ke spuštění kódu shellu) 10.4.2 Linux/ADM, 1998 (napodobenina červa Morris) 10.4.3 Vypuknutí epidemie červa CodeRed, 2001 (injektování kódu) 10.4.4 Červ Linux/Slapper, 2002 (příklad přetečení heapu)

299 301 302 302 302 302 303 304 304 305 307 308 312 313 314 315 315 317 318 319 320

323 324 324 324 325 326 326 326 328 335 348 348 350 351 353

13 10.4.5 Červ W32/Slammer, leden 2003 (miničerv) 10.4.6 Červ Blaster, srpen 2003 (útok pomocí shellkódu na Win32) 10.4.7 Obecné použití přetečení bufferu v počítačových virech 10.4.8 Popis W32/Badtrans.B@mm 10.4.9 Exploity v W32/Nimda.A@mm 10.4.10 Popis W32/Bolzano 10.4.11 Popis VBS/Bubbleboy 10.4.12 Popis W32/Blebla 10.5 Shrnutí Odkazy

358 361 363 363 364 364 366 366 367 368

Část II – Strategie obránce Kapitola 11 Techniky antivirové obrany 11.1 Skenery první generace 11.1.1 Skenování řetězců 11.1.2 Zástupné znaky 11.1.3 Neshody 11.1.4 Generická detekce 11.1.5 Hašování 11.1.6 Záložky 11.1.7 Skenování začátku a konce 11.1.8 Skenování vstupních a fixních bodů 11.1.9 Hyper-rychlý přístup k disku 11.2 Skenery druhé generace 11.2.1 Chytré skenování 11.2.2 Detekce struktury 11.2.3 Téměř přesná identifikace 11.2.4 Přesná identifikace 11.3 Algoritmické skenovací metody 11.3.1 Filtrování 11.3.2 Statická detekce decryptoru 11.3.3 Rentgenová metoda (X-raying) 11.4 Emulace kódu 11.4.1 Detekce zakódovaných a polymorfních virů s použitím emulace 11.4.2 Dynamická detekce decryptoru 11.5 Příklady detekce metamorfních virů

373 375 376 377 378 379 379 379 380 381 381 382 382 382 382 383 385 386 388 389 393 397 400 401

14 11.5.1 Geometrická detekce 11.5.2 Disassemblovací techniky 11.5.3 Použití emulátorů pro trasování 11.6 Heuristická analýza 32bitových virů pro Windows 11.6.1 Vykonávání kódu začíná v poslední sekci 11.6.2 Podezřelé příznaky sekce 11.6.3 Nesprávná virtuální velikost v PE hlavičce 11.6.4 Možné "díry" mezi sekcemi 11.6.5 Podezřelé přesměrování kódu 11.6.6 Podezřelé jméno kódové sekce 11.6.7 Možná infekce hlavičky 11.6.8 Podezřelé importy z KERNEL32.DLL přes pořadová čísla 11.6.9 Tabulka importovaných adres je přepsaná 11.6.10 Vícenásobné PE hlavičky 11.6.11 Vícenásobné hlavičky Windows a podezřelé importy z KERNEL32.DLL 11.6.12 Podezřelé relokace 11.6.13 Pevné ukazatele na systémové oblasti 11.6.14 Nekonzistence knihovny KERNEL32.DLL 11.6.15 Načítání sekce do adresního prostoru VMM 11.6.16 Nesprávná velikost kódu v hlavičce 11.6.17 Příklady kombinací podezřelých příznaků 11.7 Heuristická analýza používající neuronové sítě 11.8 Obyčejné a generické metody dezinfekce 11.8.1 Standardní dezinfekce 11.8.2 Generické decryptory 11.8.3 Jak generický dezinfektor funguje?

11.8.4 Jak si může být dezinfektor jistý, že je soubor infikován?

11.8.5 Kde je původní konec hostitelského souboru?

11.8.6 Kolik druhů virů můžeme takto odstranit?

11.8.7 Příklady heuristiky pro generické léčení 11.8.8 Příklady generické dezinfekce 11.9 Očkování 11.10 Systémy řízení přístupu 11.11 Kontrola integrity 11.11.1 Falešné poplachy 11.11.2 Prvotní čistý stav 11.11.3 Rychlost 11.11.4 Speciální objekty

402 402 403 406 407 407 407 407 408 408 408 408 408 408 408 409 409 409 409 410 410 411 412 413 414 414 415 415 415 416 417 418 419 420 420 421 421 421

15 11.11.5 Nezbytné změny v objektech 11.11.6 Možná řešení 11.12 Monitory podezřelého chování 11.13 Sand-Boxing 11.14 Závěr Odkazy

Kapitola 12 Skenování paměti a dezinfekce 12.1 Úvod 12.2 Systém virtuální paměti ve Windows NT 12.3 Virtuální adresovací prostor 12.4 Skenování paměti v uživatelském režimu 12.4.1 Tajemství funkce NtQuerySystemInformation() 12.4.2 Obecné procesy a speciální systémová práva 12.4.3 Viry v subsystému Win32 12.4.4 Viry Win32 alokující privátní stránky 12.4.5 Viry nativních služeb Windows NT 12.4.6 Viry Win32, které používají proceduru skrytého okna 12.4.7 Viry Win32, které jsou součástí spustitelného obrazu 12.5 Skenování paměti a stránkování 12.5.1 Vyhodnocení procesů a skenování obrazů v souborech 12.6 Dezinfekce paměti 12.6.1 Ukončení procesu, který obsahuje kód viru 12.6.2 Detekce a ukončování threadů virů 12.6.3 Záplatování virového kódu v aktivních stránkách 12.6.4 Postup dezinfekce zavedených DLL a běžících aplikací 12.7 Skenování paměti v režimu jádra 12.7.1 Skenování uživatelského adresovacího prostoru procesů 12.7.2 Rozlišení vstupních bodů API služeb NT 12.7.3 Důležité funkce NT pro skenování paměti v režimu jádra 12.7.4 Kontext procesu 12.7.5 Skenování horních 2 GB adresovacího prostoru 12.7.6 Jak lze deaktivovat virus ve filtrovacím ovladači?

12.7.7 Paměť jádra, která je pouze pro čtení 12.7.8 Skenování paměti v režimu jádra na 64bitových platformách 12.8 Možné útoky proti skenování paměti 12.9 Shrnutí a budoucnost Odkazy

422 422 422 424 425 425

429 431 432 434 438 438 439 440 441 443 443 443 446 448 448 448 448 451 452 453 453 453 454 455 455 456 458 458 461 462 463

16 Kapitola 13 Techniky blokování červů a ochrany před pronikáním na bázi hostitele 465 13.1 Úvod 13.1.1 Blokování skriptů a SMTP červů 13.1.2 Blokování nových útoků – CodeRed a Slammer 13.2 Techniky blokování útoků využívající přetečení bufferu 13.2.1 Přezkoumání kódu 13.2.2 Řešení na úrovni kompilátoru 13.2.3 Řešení na úrovni operačního systému a rozšíření run-time 13.2.4 Rozšíření subsystému – Libsafe 13.2.5 Rozšíření režimu jádra 13.2.6 Doprovázení programů 13.3 Techniky blokování červů 13.3.1 Detekce injektovaného kódu 13.3.2 Blokování posílání: blokování kódu, který se sám rozesílá 13.3.3. Validace ovladačů výjimek 13.3.4 Techniky zmírňování útoků "return-to-LIBC" 13.3.5 Atributy stránky "GOT" a "IAT" 13.3.6 Velký počet spojení a chyby spojení 13.4 Možné budoucí útoky červů 13.4.1 Možné zvýšení počtu retro-červů 13.4.2 "Pomalí" červi pod radarem 13.4.3 Polymorfní a metamorfní červi 13.4.4 Škody velkého rozsahu 13.4.5 Automatizovaná detekce exploitů – učení se z prostředí 13.5 Závěr Odkazy

Kapitola 14 Strategie obrany na síťové úrovni 14.1 Úvod 14.2 Použití přístupových seznamů routerů 14.3 Ochrana firewally 14.4 Systémy pro detekci průniku do sítě 14.5 Systémy honeypotů

466 467 470 470 471 472 479 480 480 482 482 483 487 489 493 496 497 498 498 498 498 499 499 500 501

503 504 505 507 509 511

17 14.6 Protiútoky 14.7 Systémy včasného varování 14.8 Vzory chování červů v síti 14.8.1 Zachycení červa Blaster 14.8.2 Zachycení červa Linux/Slapper 14.8.3 Zachycení červa W32/Sasser.D 14.8.4 Zachycení požadavku ping červa W32/Welchia 14.8.5 Detekce červa W32/Slammer a souvisejících možností exploitace 14.9 Závěr Odkazy

Kapitola 15 Techniky analýzy škodlivého kódu 15.1 Vaše osobní laboratoř pro analýzu virů 15.1.1 Jak získat potřebný software?

15.2 Informace, informace, informace 15.2.1 Průvodci architekturami 15.2.2 Báze znalostí 15.3 Dedikovaná analýza virů pomocí VMWARE 15.4 Proces analýzy počítačového viru 15.4.1 Příprava 15.4.2 Dekomprese 15.4.3 Disassemblování a dešifrování 15.4.4 Techniky dynamické analýzy 15.5 Udržování sbírky škodlivého kódu 15.6 Automatizovaná analýza: Digital Immune System Odkazy

Kapitola 16 Shrnutí Doporučené čtení Informace o bezpečnosti a včasných varováních Bezpečnostní aktualizace Statistiky vypuknutí počítačových červů Dokumenty o výzkumu počítačových virů Kontaktní informace na prodejce antivirů Testeři antivirů a příbuzné stránky

Rejstřík

513 514 515 515 516 518 520 521 523 523

525 526 528 528 528 528 529 531 531 536 537 543 564 565 567

569 570 570 571 571 571 572 573

576

18

O autorovi Peter Szor je světově proslulý odborník na počítačové viry a bezpečnost. Aktivní výzkum počítačových virů vede více než než 15 let – na viry a ochranu proti nim se zaměřil už ve své diplomové práci v roce 1991. Během své kariéry Peter pracoval s nejznámějšími antivirovými produkty, jako jsou AVP, F-PROT a Symantec Norton AntiVirus. V letech 1990 až 1995 v Maďarsku vytvořil svůj vlastní antivirový program Pasteur. Kromě vývoje počítačových antivirů se Peter už roky zabývá vývojem systémů odolných proti chybám a systémům pro bezpečné finanční transakce.

V roce 1997 byl pozván do organizace CARO (Computer Antivirus Researchers Organization). Peter je také v dozorčí radě magazínu Virus Bulletin a je zakládajícím členem sítě AVED (AntiVirus Emergency Discussion). Více než pět let byl vedoucím výzkumníkem ve firmě Symantec v Santa Monice v Kalifornii.

Peter je autorem více než 70 článků na téma počítačových virů a bezpečnosti pro magazíny Virus Bulletin, Chip, Source, Windows NT Magazine, Information Security Bulletin a další. Je častým přednášejícím na konferencích, jako jsou Virus Bulletin, EICAR, ICSA nebo RSA a byl přizván i na takové bezpečnostní konference, jako je USENIX Security Symposium. Snaží se sdílet výsledky svého výzkumu a předávat své znalosti o počítačových virech a bezpečnosti ostatním.

19

Předmluva Komu je tato kniha určena V posledních dvou desetiletích se objevilo větší množství publikací na téma počítačových virů, ale pouze několik z nich bylo napsáno profesionály ("znalci") v oboru. Existuje mnoho knih, které se zabývají problematikou počítačových virů, a které se obvykle zaměřují na nováčky – z tohoto důvodu pak nejsou příliš zajímavé pro technické odborníky. Existuje pouze několik knih, které se zabývají technickými detaily, jejichž pochopení je nezbytné pro efektivní obranu proti počítačovým virům.

Součástí problému je i to, že existující knihy obsahují jen málo komplexních informací o aktuálních počítačových virech. Postrádají například důležité technické informace o rychle se šířících počítačových červech, které k napadení cílových systémů exploitují jejich zranitelnosti, nebo se nezabývají posledními technikami v oblasti evoluce kódu, jako je třeba metamorfismus. Pokud byste chtěli získat všechny informace, které jsou obsaženy v této knize, museli byste strávit mnoho času čtením článků, které lze jen obtížně vyhledávat v konferencích, zabývajících se počítačovými viry a bezpečností. K získání důležitých detailů byste se museli také roky zabývat zkoumáním škodlivého kódu.

Věřím, že tato kniha bude velice užitečná IT odborníkům a bezpečnostním profesionálům, kteří každodenně bojují proti počítačovým virům. V současné době musí systémoví administrátoři, stejně jako domácí uživatelé, bojovat s počítačovými červi a dalšími škodlivými programy ve svých sítích. Různé bezpečnostní kurzy se velmi málo věnují tématu ochrany proti počítačovým virům, přičemž široká veřejnost toho ví ještě méně o analýze a ochraně sítí proti takovým útokům. Faktem ovšem je, že techniky analýzy počítačových virů zatím ještě nebyly v žádné práci popsány v dostatečné míře.

Myslím si, že pro každého, kdo se zabývá počítačovou bezpečností, je důležité vědět, čeho všeho již autoři počítačových virů dosáhli.

Po mnoho let se výzkumníci počítačových virů soustředili na "soubory" nebo "infikované objekty". Na druhé straně jsou bezpečnostní profesionálové více než znepokojeni podezřelými událostmi probíhajícími na úrovni počítačové sítě. Hrozby typu červa CodeRed pracují tak, že prostřednictvím počítačové sítě injektují svůj kód do paměti zranitelných procesů, ale "neinfikují" soubory na disku. Z toho vyplývá, že dnes je důležité rozumět všem těmto perspektivám (jak samotným souborům a ukládání informací do nich, tak i obsahu paměti a počítačové síti) a pomocí technik analýzy škodlivého kódu hledat souvislosti mezi vzniklými událostmi.

Během let jsem trénoval mnoho bezpečnostních analytiků, aby dokázali efektivně pracovat s nebezpečími plynoucími ze škodlivého kódu, a reagovat na ně. V této knize jsou obsaženy informace o všem, s čím jsem kdy pracoval. Uvádím například důležité informace o starých hrozbách, jako jsou 8-bitové viry pro počítač Commodore 64. Uvidíte, že techniky, jako je například technika stealth, se objevovaly už v dřívějších počítačových virech a na mnoha platformách. Tím si uvědomíte, že současné rootkity rozhodně nepředstavují nic nového! V knize naleznete dostatečně pokrytá témata, která se věnují nejenom hrozbám 32-bitových a 64-bitových červů pro Windows, ale i nebezpečím číhajícím na mobilních zařízeních, společně s obsáhlým popisem souvisejících exploitů. Mým cílem je nejenom ilustrovat, jak

20 se mnoho starých technik "reinkarnováno" do nových hrozeb, ale také předvést moderní útoky s uvedením technických detailů.

Jsem si jist, že mnoho z vás se připojí k boji proti škodlivému kódu a stejně jako já vyvinou nové techniky obrany. Přitom je však potřeba si uvědomovat i nebezpečí a výzvy v tomto oboru!

O čem je tato kniha Účelem této knihy je demonstrovat současný stav oboru počítačových virů a vývoje antivirů a naučit vás metodám analýzy počítačových virů a ochraně proti nim. Popisuji zde techniky infekce počítačovými viry ze všech možných perspektiv – souborů (ve smyslu uložení obsahu), paměti a počítačové sítě. Dozvíte se všechno o špinavých tricích počítačových virů, které byly v posledních dvou desetiletích vytvořeny těmi na druhé straně, a také o tom, jak pracovat se složitostmi polymorfního kódu a exploitů.

Nejjednodušší cestou, jak číst tuto knihu, je postupovat od jedné kapitole ke druhé. Některé kapitoly popisující útok ovšem mohou získat na své důležitosti poté, co si přečtete kapitoly, pojednávající o příslušných způsobech obrany. Pokud cítíte, že vám některá kapitola není po chuti nebo je příliš dlouhá nebo obtížná, můžete ji přeskočit. Jsem si jistý, že každý čtenář podle svých zkušeností shledá některé části jako jednoduché a jiné jako obtížnější.

Předpokládám, že čtenář této knihy je na jisté úrovni obeznámen s technologiemi a programováním. Je zde popsáno tolik věcí, že je naprosto nemožné, aby se kniha zabývala všemi tématy do nejmenších detailů. Vše, co budete potřebovat k úspěšnému boji proti počítačovým virům, se však určitě dozvíte jinde.

A abych vám v tomto ohledu pomohl, přidal jsem ke každé kapitole obsáhlý seznam odkazů, který vás navede k podrobnějším informacím.

Tato kniha určitě mohla mít více než 1000 stran. Jak jsem však řekl – nejsem Shakespeare. Mám znalosti počítačových virů, nikoliv angličtiny. Pokud by kniha byla psána jinak, neměli byste z ní velký užitek.

O čem tato kniha není V knize nepíšu nic o programech trojských koňů, a v celém rozsahu se nevěnují "zadním vrátkám" v programech. Tato kniha je v prvé řadě o škodlivém kódu, který se sám replikuje. O škodlivých programech jako takových existuje spousta dobrých knih (narozdíl od tématu počítačových virů).

V této knize neuvádím žádný zdrojový kód, který by mohl být přímo použit k vytvoření jiného viru.

Tato kniha není o tom, jak vytvářet viry. Rozumím však tomu, že autoři virů zpravidla znají většinu technik, které uvádím v této knize. Aby vyvinuli svoje vlastní techniky obrany, musí se "ti dobří" dozvědět více a začít přemýšlet (nikoliv však jednat) jako skuteční útočníci! Je zajímavé, že se mnoho univerzit snaží vyučovat výzkum počítačových virů tak, že nabízí kurzy jejich psaní. Může opravdu pomoci to, že je student schopen napsat virus, který infikuje miliony systémů po celém světě? Budou mít takoví studenti lepší znalosti vývoje lepších technik obrany? Odpověď na tuto otázku je pochopitelně záporná.

Výuka by raději měla zaměřit na analýzu existujícího škodlivého kódu. Existuje mnoho hrozeb, které čekají na svůj rozbor a na to, až bude proti nim něco podniknuto.

Znalost počítačových virů je něco jako "Síla" ve Hvězdných válkách. Podle způsobu použití "Síly" může tato znalost působit dobro nebo zlo. Nemůžu vás ovšem přimět zůstat mimo Temnou stranu...

21

Poděkování Nejdříve bych chtěl poděkovat své ženě Natalii za to, že mě v mé práci více než 15 let povzbuzovala! Také bych jí chtěl poděkovat za to, že tolerovala všechen čas, který jsem věnoval psaní knihy o víkendech, místo toho, abych se věnoval jí samotné.

Chtěl bych poděkovat všem, kteří umožnili vznik této knihy. Ta vzešla ze série článků o počítačových virech, z nichž jsem některé během let sepsal já, společně s dalšími výzkumníky. Nemohu proto dostatečně poděkovat Ericu Chienovi, Peterovi Ferriemu, Bruce McCorkendaleovi a Fredericu Perriotovi za jejich velký přínos ke kapitolám 7 a 10.

Tato kniha by nemohla být napsána bez pomocí mnoha přátel, antivirových odborníků a kolegů. Na prvním místě bych chtěl poděkovat Dr. Vesselinu Bontchevovi za to, že mě během mnoha let spolupráce naučil spoustu věci o terminologii škodlivých programů. Vesselin je známý svou pečlivostí a můj výzkum velmi ovlivnil a podpořil.

Velký dík patří těmto lidem, kteří mě povzbudili při psaní této knihy, předali mi hodně svých znalostí a během let ovlivňovali můj výzkum: Oliver Beke, Zoltan Hornak, Frans Veldman, Eugene Kaspersky, Istvan Farmosi, Jim Bates, Dr. Frederick Cohen, Fridrik Skulason, David Ferbrache, Dr. Klaus Brunnstein, Mikko Hypponen, Dr. Steve White, a Dr. Alan Solomon.

Velký dík dlužím svým technickým recenzentům, kterými jsou Dr. Vesselin Bontchev, Peter Ferrie, Nick FitzGerald, Halvar Flake, Mikko Hypponen, Dr. Jose Nazario a Jason V. Miller. Vaše podpora, kritika, porozumění a recenzování první verze rukopisu byly opravdu neocenitelné.

Chtěl bych poděkovat Janosi Kisovi a Zsoltu Szoboszlaymu, kteří mi poskytli přístup k virovým kódům v době, kdy centrem počítačového světa byla BBS. Také chci poděkovat Gunter May za největší dárek, který může dítě z východní Evropy dostat – C64.

Velký dík patří všem lidem v Symantecu, zejména však Lindě A. McCarthyové a Vincentu Weaferovi, kteří mě při psaní této knihy velice povzbudili. Chtěl bych poděkovat také Nancy Connerové a Chrisu Andrymu za jejich vynikající práci při editaci knihy. Bez jejich pomoci by tento projekt nebyl nikdy dokončen. Velký dík dlužím i Jessice Goldsteinové, Kristy Hartové a Christy Hackerdové, kteří mi pomáhali s procesem publikování.

Velký dík rovněž patří všem bývalým a současným členům CARO (Computer Antivirus Researchers Organization), VFORUM a AVED (AntiVirus Emergency Discussion) za zajímavé diskuse nejenom o počítačových virech a jiných škodlivých programech, ale také o systémech obrany.

Chtěl bych poděkovat všem lidem ve Virus Bulletinu za to, že po více než 10 let mezinárodně publikovali mé články, a že mi umožnili použít tento materiál pro tuto knihu.

Chtěl bych poděkovat svým rodičům a prarodičům za velké "domácí vzdělání" v matematice, fyzice, hudbě a historii.

22

Kontakt na autora Naleznete-li v této knize chyby, nebo pokud máte náměty na to, co by nemělo chybět v případném v budoucím vydání, velmi rád se o tom dozvím. Na své webové stránce plánuji uvádět podrobnější vysvětlení, případné korekce knihy, a také nové informace, které se vztahují k obsahu této knihy. Ačkoliv jsem vynaložil veškeré úsilí, abych vám poskytnul "důvěryhodné" informace podle mých nejlepších znalostí, myslím si, že práce takového rozsahu a složitosti nemůže existovat bez jakýchkoliv nedostatků. Věřím, že na tyto eventuální nedostatky budete pohlížet s porozuměním.

Peter Szor Santa Monica, CA pszor@acm.org http://www.peterszor.com

ČÁST I

STRATEGIE ÚTOČNÍKA

KAPITOLA 1 Úvod do her přírody

"Umění je pro mě vyjádřením touhy komunikovat."

- Endre Szasz

26

Kapitola 1 – Úvod do her přírody

Výzkum počítačových virů je fascinujícím zdrojem podnětů pro všechny se zájmem o přírodu, biologii a matematiku. Každý uživatel výpočetní techniky se pravděpodobně setká se stále běžnějším problémem počítačových virů. Velká část současných výzkumníků na poli počítačových virů se o ně začala zajímat poté, co jimi byly před desetiletími infikovány jejich vlastní systémy.

Kniha Donalda Knutha1, The Art of Computer Programming, naznačuje, že cokoliv, co dokážeme pomocí výpočetní techniky popsat, je věda, ale to, co popsat nedokážeme, je umění. Výzkum v oblasti počítačových virů je bohatý, komplexní a mnohostranný obor. Zahrnuje reverzní inženýrství, rozvíjení možností detekce, odstraňování infekce a obranu systémů pomocí optimalizovaných algoritmů, takže má přirozeně vědecký základ, nicméně některé analytické metody mají k umění velmi blízko. To je také důvodem, proč je pro nezasvěcené tento poměrně mladý obor tak těžko pochopitelný. Dokonce i po mnoha letech výzkumu spadá mnoho nových analytických metod spíše do kategorie umění a naučit se jim je možné pouze ve firmách zabývajících se poskytováním antivirových a bezpečnostních produktů, nebo být zocelen skrze osobní styk s nimi. Teprve poté může být člověk úspěšným na tomto poli.

V této knize se snažím poskytnout čtenáři zasvěcený náhled do tohoto fascinujícího výzkumu. Budete mít možnost se naučit různá fakta, která by snad měla zaujmout jak studenty umění, tak i odborníky v oblasti výpočetní techniky. Mým cílem je vám poskytnout rozšíření znalostí nejenom o útočnících, ale také o systémech vybudovaných na ochranu proti škodlivým programům.

Dnes je na trhu mnoho knih o počítačových virech, ale jenom pár z nich je napsáno lidmi s takovými zkušenostmi v oblasti výzkumu, které jsou potřebné pro diskusi o tomto tématu s technicky orientovaným publikem.

Následující sekce knihy budou rozebírat historické milníky výpočetní techniky, které jsou pro téma počítačových virů důležité. Postupně se tak propracujeme k praktické definici počítačového viru.

1.1 Rané modely sebereplikujících struktur Lidé se ve snaze popsat náš svět z různých úhlů snaží vytvářet stále nové modely. Představa systémů schopných vlastní reprodukce, které modelují struktury vlastní reprodukce, je známa od roku 1948, kdy ji navrhl američan maďarského původu Neumann János (John von Neumann)2, 3, 4.

Von Neumann byl matematik, úžasný myslitel a jeden z největších tvůrců v oblasti výpočetní techniky. Dnešní počítače jsou vytvářeny na základě jeho původních vizí. Neumann zavedl pojem paměti pro ukládání informací a binární (opak analogové) operace. Dle von Neumannova bratra Nicholase byl "Johnny" doslova ohromen Bachovým "Uměním fugy", neboť byla napsána pro mnoho hlasů, aniž by byly specifikovány nástroje. Nicholas von Neumann přičítá tomuto Bachovu dílu zásluhu coby zdroji inspirace pro počítač s uloženými programy5.

V tradičním von Neumannově přístroji nebyl rozdíl mezi programy a daty. Program byl od dat rozlišen pouze tehdy, když operační systém předal řízení a vykonal informace zde uložené.

Oddělení dat od programu je nutné pro vytvoření systémů s větší bezpečností. Takový přístup však bohužel přináší i slabiny.

Počítačové viry – analýza útoku a obrana

27

Moderní počítače umí za pomoci mnoha modelovacích technik simulovat přírodu. Mnoho počítačových simulací má podobu hry. Moderní počítačové viry jsou sice poněkud odlišné od tradičních systémů pro simulaci přírody, ale studenti zabývající se výzkumem virů jistě ocení užitečnost podobných her pro pochopení struktur vlastní reprodukce.

1.1.1 John von Neumann: Teorie automatů schopných vlastní reprodukce Rozmnožování je neodmyslitelná součást života. John von Neumann jako první poskytl model popisující vlastní reprodukci přírody pomocí představy automatů schopných vlastní reprodukce.

V této představě von Neumann pracuje se třemi částmi: 1. Univerzální stroj.

2. Univerzální konstruktor.

3. Informace na pásce.

Univerzální stroj (Turingův stroj) díky čtení paměťové pásky a použití informací na ní uložených je schopen znovu postavit sám sebe, kousek po kousku, za pomoci univerzální stavební jednotky. Stroj nechápe samotný proces, pouze následuje instrukce (plán) na paměťové pásce. Stroj by měl být schopen vybrat díl ze sady všech dílků tak, že bere jeden za druhým a porovnává je se vzorem, dokud nenalezne ten pravý. Poté co jej nalezne, propojí jej s minulým a pokračuje, dokud se nezkopíruje celý.

Pokud bylo informaci nutnou k sestavení dalšího systému možno z pásku přečíst, pak to znamenalo, že stroj byl schopen reprodukce sebe sama. Nově postavené automaty jsou následně spuštěny, což spustí stejný proces nanovo.

Obrázek 1.1

Model stroje schopný vlastní reprodukce.

28

Kapitola 1 – Úvod do her přírody

O několik let později Stanislaw Ulam navrhl von Neumannovi, aby k popisu tohoto modelu použil procesy buněčné automatizace. Namísto "dílů stroje" tak byly použity stavy buněk. Protože se s buňkami operuje ve stylu robotů pomocí pravidel ("kód"), je buňka pojmenována termínem robot. Sada buněk pak představuje počítačovou architekturu buněčných automatů (CA).

Von Neumann pozměnil původní model za použití buněk, které měly 29 různých stavů ve dvou-dimenzionálním pěti-prvkovém prostředí. Na vytvoření struktury schopné vlastní reprodukce potřeboval 200 tisíc buněk. Von Neumannův model matematicky dokázal možnost struktur schopných vlastní reprodukce – regulérní neživé částice (molekuly) mohou být složeny tak, aby vytvářely struktury schopné vlastní reprodukce (potenciálně živé organismy).

V září 1948 von Neumann uvedl svou vizi systémů automatů schopných vlastní reprodukce. Pouhých 5 let poté Watson a Crick zjistili, že živé organismy používají molekuly DNA jako "pásku", která poskytuje živým organismům informace potřebné k reprodukci.

Je smutné, že tohoto potvrzení své práce se von Neumann už nedožil, nicméně jeho práce byla dokončena Arthurem Burksem. Další práci vytvořil E.F. Codd v roce 1968. Codd zjednodušil von Neumannův model za použití buněk s osmi stavy v pěti-prvkovém prostředí. Podobné zjednodušování se stalo základem pro "smyčky vlastní reprodukce" (self-replicating loops)6 používané výzkumníky v oblasti umělé inteligence, jako například Christopherem G. Langtonem v roce 1979. Těmito smyčkami se eliminuje složitost univerzálního stroje a dovoluje se spíše zaměřit na potřeby replikace.

V roce 1980 v NASA/ASEE vedli Robert A. Freitas ml. a William B. Zachary7 výzkum zaměřený na základnu na Měsíci schopnou vlastní reprodukce a rozšiřování. Za pomoci teorie automatů schopných vlastní reprodukce a teorie automatizace tak byla zkoumána možnost tzv. měsíčního výrobního zařízení (lunar manufacturing facility – LMF). Robert A. Freitas ml. společně s Ralphem C. Merklem nedávno publikovali knihu pojmenovanou jako Kinematic Self-Replicating Machines (Kinematické stroje schopné vlastní reprodukce). Tato kniha ukazuje obnovený zájem vědců o tuto oblast. Před několika lety použil Freitas nový termín ecophagy (ekofágie), který představuje teoretickou možnost zničení celého ekosystému nano-roboty schopnými vlastní reprodukce, kteří by se vymkli kontrole, a navrhuje, jakými způsoby se mělo postupovat pro zmírnění následků8.

Stroje se schopností vlastní replikace jsou také opakovaně součástí science fiction – od filmů jako Terminátor až k novelám autorů jako Neal Stephenson nebo William Gibson. A je pravdou, potvrzenou mnoha případy z celého světa, že to, co často bývalo doménou science fiction, jak víme z příkladů nanotechnologií a systémů mikroelektronického mechanického inženýrství (MEMS), je dnes skutečným vědeckým oborem.

1.1.2 Fredkin: Reprodukční struktury Mnozí se dále pokoušeli zjednodušovat von Neumannův model. Příkladem může být Edward Fredkin, který v roce 1961 sestavil model za použití robota se zvláštními pravidly, kde každá struktura měla schopnost vlastní reprodukce a replikace na síti (viz obrázek 1.2). Fredkinova pravidla pro automaty9 byla tato: 

Na ploše existuje pouze jeden typ symbolu.



Na každé možné pozici buď symbol je nebo není.

Počítačové viry – analýza útoku a obrana

29



Generace symbolů následují po sobě v konečném časovém rámci.



Okolí každého symbolu určí, zdali bude v další generaci obsahovat symbol.



Okolí je reprezentováno čtverci nad, pod, vlevo a vpravo od symbolu (stejně jako pětiprvkové prostředí známé od von Neumanna).



Stav čtverce v další generaci bude prázdný v případě, pokud má symbol sudé množství symbolů ve svém okolí.



Stav čtverce v další generaci bude plný v případě, pokud má symbol liché množství symbolů ve svém okolí.



Počet stavů je možno měnit.

Obrázek 1.2

Generace 1, Generace 2 a ... Generace 4.

1.1.3 Conway: Hra života V roce 1970 vytvořil John Horton Conway10 jeden z nejzajímavějších systémů buněčných automatů.

Podobně jako jeho předchůdci Conway zkoumal interakce jednoduchých prvků řídících se jednoduchými pravidly a zjistil, že to může vést k překvapivým výsledkům. Conway svou hru pojmenoval jako Life (život). Hra je založena na následujících pravidlech: 

Neměl by existovat počáteční vzor, pro který platí jednoduchý důkaz, že populace poroste bez omezení.



Může existovat vzor, který zdánlivě poroste dál bez omezení.



Měly by existovat počáteční vzory, které fungují podobným způsobem jako jednoduché zákony genetiky – zrození, přežití a smrt.

Obrázek 1.3 na následují straně demonstruje moderní reprezentaci původní Conwayovy hry v podání Edwina Martina11.

30

Obrázek 1.3

Kapitola 1 – Úvod do her přírody

Macovská implementace hry Life s počátečním rozmístěním struktury "střelce".

Obzvláště zajímavá je animace vzniklá při rozmístění do tzv. struktury střelce. V několika generacích se vyvinou dvě pozice, které vypadají, jako by po sobě střílely (viz obrázek 1.4) a poté, co tak učiní, vyprodukují kluzáky, které "odletí" pryč (viz obrázek 1.5) směrem ke spodnímu rohu obrazovky a tato sekvence se opakuje stále dokola, jak jsou tvořeny nové kluzáky.

Obrázek 1.4

"Střelec" v generaci 355.

Počítačové viry – analýza útoku a obrana

Obrázek 1.5

31

Kluzák se pohybuje, aniž by měnil počet svých částí.

Na dvou-dimenzionální ploše má každá buňka dva možné stavy: buď S=1, pokud na ní je symbol nebo S=0, pokud na ní symbol není. Každá buňka se tedy bude vyvíjet v závislosti na prostředí (viz obrázek 1.6).

Obrázek 1.6

Moorovo prostředí s devíti prvky.

Následující pravidla definují Conwayovu hru Life:  Zrození – Pokud jsou v okolí prázdné buňky právě tři (K=3) zaplněné buňky, bude tato buňka

v příští generaci zaplněna.  Přežití – Pokud jsou v okolí plné buňky dvě nebo tři (K=2 nebo K=3) jiné zaplněné buňky, tato

zaplněná buňka přežije do další generace.  Smrt – Pokud je v okolí zaplněné buňky jedna nebo žádná plná buňka (K=1 nebo K=0), zemře

tato buňka v příští generaci na samotu. A dále – pokud je kolem buňky příliš mnoho zaplněných buněk – čtyři, pět, šest, sedm nebo dokonce osm (K=4, 5, 6, 7 nebo 8) – zemře tato buňka v příští generaci z důvodu přelidnění.

Conway původně věřil, že v jeho hře neexistují struktury schopné vlastní reprodukce. Dokonce nabídl $50 každému, kdo dokáže vytvořit strukturu, která bude schopna vlastní reprodukce. Právě taková struktura byla rychle nalezena skupinou zabývající se umělou inteligencí na Massachusettském institutu technologií (MIT), kdy byla využita výpočetní technika.

Studenti MIT tuto strukturu pojmenovali jako kluzák. Pokud dojde k setkání třinácti kluzáků, vytvoří se pulzující struktura, která začne velmi rychle "rodit" další kluzáky. Od této chvíle je každou další třicátou generaci připraven nový kluzák, který je schopný opustit plochu. Tato sekvence pokračuje stále dál a dál.

Toto nastavení je podobné struktuře střelce, známé z obrázků 1.3 a 1.4.

32

Kapitola 1 – Úvod do her přírody

Kniha Games with Computers (Hry s počítači) od autorů Antala Csakanyho a Ference Vajdy z roku 1980 obsahuje ukázky soupeřících her. Autoři zde popisují deskovou hru podobnou hře Life, kdy je za pomoci pojmů jako kapusta, zajíc a liška popisován boj o přežití v přírodě. Původní buňka je zaplněna kapustou, coby potravou pro zajíce, kteří se poté (podle definovaných pravidel) stávají potravou lišek. Za pomoci zmiňovaných pravidel je možné ovládat a vyvažovat populaci zajíců a lišek.

Je velmi zajímavé uvažovat o výpočetní technice, počítačových virech a antivirových programech v termínech tohoto modelu. Bez výpočetní techniky (zvláště pak operačního systému nebo nějakého druhu BIOSu) by počítačové viry nebyly schopny reprodukce. Viry infikují další systémy a jak se dále šíří, můžeme je považovat za kořist a uvažovat o antivirových programech jako o jejich lovcích.

V některých případech se viry dokáží bránit. Tuto schopnost označujeme pojmem retroviry. V těchto případech může být antivirový program doslova "zabit". A naopak – pokud je virus zastaven antivirovým programem, dá se říci, že byl "zabit" on. A v některých případech je krátce po infekci "zabit" hostitelský počítač.

Například – pokud virus bez okolků smaže klíčové soubory operačního systému, systém zhavaruje a virus tak "zabije" svého hostitele. Pokud se to stane příliš rychle, je vysoká pravděpodobnost, že virus svého hostitele zabije dříve, než dostane šanci se sám rozmnožit. Když si představíme miliony počítačů jako deskovou hru tohoto druhu, je fascinující pozorovat, jak jsou modely populace počítačových virů a antivirů podobné těm z deskové hry s kapustou, zajíci a liškami.

Jednotlivá pravidla, vedlejší účinky mutace, reprodukční techniky a stupně nakažlivosti vedou k vytvoření rovnováhy mezi těmito programy a dávají tušit nekonečný souboj. Stejně tak jsme svědky "spolu-evoluce"12, která existuje mezi počítačovými viry a antivirovými programy. Podobně jako antivirové programy, nabývají na složitosti i samotné viry. Tento trend je po více než třicetileté historii počítačových virů stále platný.

Pomocí podobných modelů můžeme sledovat, jak se populace virů vyvíjí dle množství vzájemně kompatibilních počítačů. Pokud je řeč o antivirových programech a virech, probíhá na obou stranách velké množství mnohonásobně paralelních her. Prostředí pro viry, které je složeno z většího množství napadnutelných systémů, představuje oblast větší nakažlivosti a samozřejmě se tím také zvyšuje rychlost šíření virů. Velké množství stejných počítačů se vzájemně kompatibilními operačními systémy vytváří homogenní prostředí – živnou půdu pro nákazu (zní vám to povědomě?).

Na menší herní ploše býváme svědky menších vzplanutí mezi relativně malou populací virů.

Tento způsob modelování jasně vysvětluje, proč se většina útoků odehrává na operačních systémech Windows, které představují cca 95% současné PC populace kolem nás. Samozřejmě by bylo zcela naivní si myslet, že 5% počítačových systémů nestačí ke vzniku některého z typů epidemie.

Poznámka Pokud vás zaujaly struktury schopné vlastní replikace, vlastní opravy a vývoje, navštivte projekt BioWall na adrese http://lslwww.epfl.ch/biowall/index.html.

Počítačové viry – analýza útoku a obrana

33

1.1.4 Války o jádro: bojující programy Kolem roku 1966 se Robert Morris St., budoucí vedoucí vědeckého oddělení NSA, rozhodl společně se svými přáteli Victorem Vyssotskym a Dennisem Ritchiem navrhnout herní prostředí a naprogramovat hru, kterou posléze pojmenovali jako Darwin. (Morris mladší se stal prvním proslulým autorem počítačových červů v historii. Toto bude vysvětleno dále v knize.)

Původní verze programu Darwin byla určena pro PDP-1 (programovatelný datový procesor) v laboratořích Bell. Později se program Darwin přejmenoval na počítačovou hru nazvanou jako Core War, kterou dodnes hraje mnoho matematiků a programátorů (a také hackerů).

Poznámka V této knize používám termín hacker v jeho původním pozitivním významu. Stejně tak se domnívám, že všichni kvalitní výzkumníci počítačových virů jsou v tomto tradičním smyslu hackery. Sám se také považuji za hackera – ovšem zásadně odlišného od zločinných hackerů, kteří se nabourávají do počítačů jiných lidí.

Hra je pojmenována Core War (boj o jádro) z toho důvodu, protože cílem hry je zabít programy oponenta jejich přepsáním. Původní hra byla soubojem dvou programů ve strojovém kódu vytvořených v jazyce Redcode. Programy Redcode běží v jádru simulovaného stroje, pojmenovaného jako Memory Array Redcode Simulator (MARS). Zmíněný souboj obou soupeřících programů pak dal hře její název – tedy boj o jádro.

Původní sada instrukcí jazyka Redcode se sestává z deseti jednoduchých instrukcí umožňujících pohyb z jedné lokace v paměti do jiné, což poskytuje velkou flexibilitu při tvorbě záludných soupeřících programů. Dewdney je autorem mnoha článků z řady "Computer Recreations" publikovaných v časopise Scientific American13,14, kde probírá problematiku této hry (počínaje článkem z května 1984). Obrázek 1.7 ukazuje obrazovku implementace nazvané PMARSV vytvořené Albertem Ma, Na’ndorem Siebenem, Stefanem Strackem a Mintardjo Wangsawem. Pozorovat maličké bojovníky soupeřící v prostředí MARS je nakažlivě zábavné.

34

Obrázek 1.7

Kapitola 1 – Úvod do her přírody

Bojovníci z Core Wars (Dwarf a MICE).

V každoročních turnajích se bojuje o titul Král hory – (King of the Hill, KotH). Jsou to programy napsané v jazyce Redcode, které jsou schopny překonat své spoluzávodníky.

První turnaj se podařilo vyhrát programu jménem MICE. Jeho autor Chip Wendell obdržel jako trofej desku jádra paměti z raného modelu počítače CDC 660014.

Nejjednodušší z programů obsahuje pouze jednu instrukci MOV: MOV 0,1 (v tradičním zápisu). Tento program se jmenuje IMP a způsobuje to, že obsah s relativní adresou 0 (jmenovitě MOV nebo move, posun instrukce samotné), je přesunut na relativní adresu 1, právě o jeden krok před sebe samotného.

Poté je předána kontrola adrese, na kterou se instrukce přesunula, spustí se další instrukce, a poté, co se tato přesune na novou lokaci, získává kontrolu tato nová adresa, opět se spustí instrukce, která v tomto kole opět vytvoří svoji kopii o adresu výše a tak to pokračuje neustále dál a dál. Toto se děje přirozeně – tak, jak jsou instrukce spouštěny z následujících vyšších adres. Počítadlo instrukcí je zvýšeno při každém provedení instrukce.

Základní jádro programu se skládá z dvou bojujících programů a 8000 buněk pro instrukce. Novější verze hry jsou určeny i pro větší množství bojovníků najednou. Bojující programy jsou omezeny na určitou startovní délku, například 100 instrukcí a každý program má konečné množství iterací – obvykle je toto číslo rovno 80000.

Původní verze jazyka Redcode obsahovala deset instrukcí, následující edice již více. Například – ve verzi z roku 1994 je použito celkem 14 instrukcí uvedených ve výpisu 1.1.

Počítačové viry – analýza útoku a obrana

35

Výpis 1.1 Instrukce hry Core War z roku 1994.

DATCA datová nálož MOVCA přesun ADDCA přidání SUBCA odebrání MULCA násobení DIVCA dělení MODCA celočíselné dělení JMPCA skok JMZCA nulou podmíněný skok JMNCA nenulově podmíněný skok DJNCA nenulově podmíněné odečtení CMPCA porovnání SLTCA přeskočení podmíněné nižší hodnotou SPLCA provedení rozdělení

Podívejme se na návod k Dewdneyho programu Dwarf (viz výpis 1.2).

Výpis 1.2 Program Dwarf Bombing Warrior. ;jméno

Dwarf

;autor

A. K. Dewdney

;verze

94.1

;datum

Duben 29, 1993

;strategie ORG

Každou čtvrtou instrukci klade datovou nálož

1

; Značí začátek spuštění s druhou ; instrukcí (ORG ve skutečnosti není použit a ; proto se nepočítá mezi instrukce).

DAT.F

#0, #0

; Ukazatel na cílovou instrukci.

ADD.AB

#4, $-1

; Zvýší hodnotu ukazatele o 4.

MOV.AB

#0, @-2

; Klade nálož na cílovou adresu

JMP.A

$-2, #0

; Odskok zpět o dvě instrukce.

Dwarf se chová dle strategie kladení datových náloží. Prvních několik řádků uvádí jméno autora programu a programu samotného, a jako takový je standardem pro Redcode roku 1994. Dwarf se pokouší zničit protivníky kladením datových náloží do cesty protivníkových operací. Je to proto, že každý bojovník, který se pokusí zpracovat datovou instrukci v MARS oblasti, zemře a protivník zvítězí.

Instrukce MOV je použita k přesunu informací do buněk oblasti MARS. (Bojovník IMP to vysvětluje poměrně jasně.) Obecný formát příkazů jazyka Redcode je ve formě kódu operátoru A, B. Proto také příkaz MOV.AB #0, @-2 nasměruje instrukci na Dwarfův příkaz DAT jeho kódu coby zdroj.

Kapitola 1 – Úvod do her přírody

36

Pole A ukazuje na příkaz DAT, protože každá instrukce má stejnou délku, a to 1. Na 0 se nachází DAT #0, #0. Proto MOV zkopíruje instrukci DAT tam, kam ukazuje B. Otázkou je, kam teď ukazuje B? Pole B ukazuje na instrukci DAT.F #0, #0. Obvykle by toto znamenalo, že nálož by byla uložena na vrcholek této instrukce, ale symbol @ mění ukazatel na nepřímý. Důsledkem použití symbolu @ je to, že se jako hodnota ukazatele použije ta hodnota, kterou obsahuje lokace, na kterou ukazuje pole B. V tomto případě ukazuje pole B na hodnotu 0 (lokace 0, kde je umístěna instrukce DAT.F).

Nicméně – první instrukcí, která bude provedena (ještě před MOV), je instrukce ADD. Poté, co se tato ADD #4, $-1 provede, je hodnota offsetu pole DAT zvýšena o 4 při každém spuštění – poprvé se změní z 0 na 4, podruhé z 4 na 8 a tak dále.

A to je důvod, proč poté, co je příkazem MOV zkopírována DAT nálož, přistane Dwarf čtyři linie (lokace) nad instrukci DAT (Viz výpis 1.3).

Výpis 1.3 Dwarfův kód po položení první nálože.

0

DAT.F #0, #8

1 ->

ADD.AB 4, $-1

2

MOV.AB #0, @-2 ; odpalovač

3

JMP.A $-2, #0

4

DAT ; Bomba 1

5

.

6

.

7

.

8

DAT ; Bomba 2

9

.

Instrukce JMP.A $-2 obrátí ovládání zpět v závislosti na svém současném offsetu, což je zde instrukce ADD, která umožňuje Dwarfovi běžet "nekonečně". Dwarf bude v kladení náloží do jádra pokračovat skoky po čtyřech buňkách, dokud se ukazatele neotočí kolem jádra a nezačnou se vracet. (Po dosažení nejvyšší možné lokace DAT se "otočí" zpět přes nulu. V případě nejvyšší hodnoty deset bude 10+1 rovno nule a 10+4 pak bude rovno třem.)

Takto Dwarf klade nálože tak dlouho, dokud nedosáhne 80000 cyklů (resp. iterací) nebo dokud nezasáhne soupeř. Ten může Dwarfa poměrně snadno zabít, neboť zůstává na stejných lokací – aby se vyhnul vlastním bombám. To ho ale vystavuje útokům protivníka.

Existuje několik běžných strategií, včetně skenování, replikace, bombardování či IMP-spirály (za pomoci instrukce SPL). Zajímavá je varianta kladení náloží pojmenovaná jako vampire (upír).

Dewdney v ní zmiňuje možnost krádeže samotné duše protivníkova bojovníka způsobem, kdy se zmocníme jeho prováděcího toku. Toto využívají tzv. bojovníci-upíři, kteří kladou do jádra nálože v podobě JMP (JUMP). Pomocí takových náloží získáme ovládání protivníka a můžeme jej přesměrovat někam jinam, kde bude vykonávat zbytečné instrukce. Tento zbytečně prováděný kód "vypálí" iterace protivníkova prováděcího toku, což dává majiteli upíra značnou výhodu.

Počítačové viry – analýza útoku a obrana

37

Tuto hru musím doporučit všem, neboť na rozdíl od psaní počítačových červů je tato hra neškodná a současně zábavná. A navíc – pokud jste fascinováni počítačovými červy, můžete v nové verzi hry propojit různé sítě a dovolit tak bojujícím programům vstupovat z jednoho zápasu do druhého a bojovat tak s novými nepřáteli na dalších strojích. Rozvoj hry do více propojené podoby umožňuje ještě přesnější simulaci červům podobných bojovníků.

1.2 Geneze počítačových virů První programy podobající se virům se objevily na mikropočítačích v osmdesátých letech. Přesto je vhodné zde zmínit dva předchůdce: program Creeper z roku 1971-72 a "infekční" verzi populární hry Johna Walkera ANIMAL pro UNIVAC15 v roce 1975.

Creeper a jeho Reaper, který se může honosit jménem prvního antiviru na světě pro síť TENEX běžící na PDP-10 v BBN, se zrodil v průběhu raného vývoje, z něhož se později vyvinul internet.

Ještě zajímavější je ANIMAL, který byl vytvořen na sálovém počítači UNIVAC 1100/42 s operačním systémem Exec-8. V lednu 1975 vytvořil John Walker (pozdější zakladatel firmy Autodesk, Inc. a spoluautor programu AutoCAD) obecnou rutinu nazvanou PERVADE16, která mohla být volána libovolným programem. Když tuto rutinu zavolal ANIMAL, prohledala všechny dostupné adresáře a zkopírovala program, který ji spustil (což byl v tomto případě ANIMAL) do každého adresáře, do kterého měl uživatel přístup. Programy se tehdy obměňovaly poměrně pomalu, na děrných páscích, ale přesto se během měsíce ANIMAL rozšířil na úctyhodné množství míst.

První viry pro mikropočítače byly napsány pro Apple-II, zhruba v roce 1982. Rich Skrenta17, student deváté třídy v Pittsburghu (v Pennsylvánii) napsal program "Elk Cloner". Ačkoliv původně nečekal, že by program fungoval, podařilo se mu ho zdárně dokončit. Jeho spolužáci považovali program za docela zábavný, na rozdíl od jeho učitele matematiky, jehož počítač byl také infikován. Elk Cloner měl payload v podobě zobrazení Skrentovy básně při každém padesátém spuštění počítače (viz obrázek 1.8) po stisknutí tlačítka reset. Při každém padesátém restartu se Elk Cloner zavěsil na ovladač tlačítka reset, takže payload mohl být spouštěn pouze pomocí tlačítka reset.

Obrázek 1.8

Elk Cloner je aktivován.

38

Kapitola 1 – Úvod do her přírody

Málokoho překvapí, že přátelství studenta a učitele nemělo po tomto incidentu dlouhé trvání. Skrenta později vytvořil mnoho počítačových her a mnoho užitečných programů a je stále v údivu nad tím, že je proslulý právě tím nejhloupějším kouskem, který kdy naprogramoval.

V roce 1982 provedli dva výzkumníci z Xerox PARC18 další rané pokusy s počítačovými červy. Tehdy ještě nebyl používán termín počítačových virů. Jeho otcem se stal v roce 1984 matematik Dr. Frederick Cohen19, který tento termín představil společně se svými ranými studiemi o jejich povaze. Cohen použil termín "počítačový virus" na doporučení svého poradce, profesora Leonarda Adlemana20, který ho vybral z novel science fiction.

1.3 Automaticky se replikující kód: teorie a definice počítačových virů Cohen poskytl formální matematický model pro počítačové viry v roce 1984. Tento model používal Turingův stroj. Je zjevné, že Cohenův formální matematický model je podobný Neumannovu modelu automatů schopných vlastní reprodukce. Dalo by se říct, že ve smyslu von Neumanna je počítačový virus buněčný automat schopný vlastní reprodukce. Pro dnešního výzkumníka již tento model nemá žádný smysl. Jedná se totiž o obecný popis funkce. Matematický model přesto poskytoval významný teoretický podklad pro formulaci problému počítačových virů.

Cohenova definice zní takto: "Virus je program, který je schopen infekce dalších programů a je schopen jejich modifikací zajistit, aby obsahovaly potenciálně se vyvíjející kopii jeho samotného."

Tato definice popisuje důležité vlastnosti počítačových virů, jako například možnost vývoje (schopnost tvorby změněné kopie svého kódu mutacemi). Přesto může být tato definice, v tom nejpřísnějším významu, zcela zavádějící.

Tím ale ani v nejmenším nechceme kritizovat Cohenův průkopnický čin. Je těžké poskytnout dokonalou definici, zvláště s ohledem na obrovské množství dnes existujících typů virů. Například tzv. companion viry (tzv. viry-společníci) nemusí nutně modifikovat data jiného programu. Protože to nepotřebují, nechovají se dle Cohenovy definice. Namísto toho šikovně využívají vlastnosti prostředí – zde operačního systému – a umisťují se pod stejným jménem před svou oběť ve spouštěcí cestě. Toto by při striktním používání Cohenovy definice činilo problémy antivirovým programům sledujícím a blokujícím chování jiných programů. Jinými slovy – pokud by takový program blokoval pouze programy, které mění kód jiného programu, tento druh virů by jim unikl.

Poznámka Cohenova matematická definice zahrnuje i viry-společníky. Slovní definice této matematické věty v lidském jazyce je značně problematická. Definovat viry za pomoci jedné věty je totiž velmi složitý problém.

Programy kontrolující integritu programů se často spoléhají na to, že kód programu zůstává s postupujícím časem beze změn. Takové programy se spoléhají na databázi (vytvořenou kdysi v minulosti)

Počítačové viry – analýza útoku a obrana

39

a předpokládají, že tento stav byl v pořádku. Tyto programy byly v té době Cohenovými favority v oblasti obrany. Je zjevné, že v případě companion virů měly šanci na úspěch pouze v případě, že uživatele varovaly o nově vzniklých souborech. Cohenův vlastní systém toto dělal. Bohužel – širší veřejnost většinou nechtěla být vyrušována hlášením o každém novém souboru, přesto však je Cohenův způsob nejbezpečnějším způsobem.

Definice doktora Cohena nerozlišuje mezi programy určenými ke kopírování sebe sama (opravdové viry) a programy, které mohou kopírovat sebe sama jako efekt toho, že slouží širšímu okruhu programů (typicky kompilátory).

Je bohužel nezpochybnitelným faktem, že se v běžném provozu budeme setkávat s různými falešnými poplachy. Například – takový Norton Commander, populární nástavba příkazového řádku, může být použit ke zkopírování svého kódu na jiný disk či síťový zdroj. Tato akce může být mylně vyložena jako vlastní replikace, zejména tehdy, pokud se jedná o přepis dřívější verze programu za novější v případě upgrade. A ačkoliv jsou podobné falešné poplachy snadno zvládnutelné, bezpochyby jsou pro koncové uživatele nepříjemné.

Pokud toto vezmeme v úvahu, může být přesnější definice počítačového viru následující: "Počítačový virus je program, který rekurzivně a explicitně kopíruje potenciálně se vyvíjející verzi sebe sama".

Není potřeba specifikovat, jak je kopírování provedeno, ani nutnost infekce či jiného způsobu modifikace jiné aplikace nebo hostitele. Přesto však většina počítačových virů využívá k převzetí kontroly modifikaci kódu jiného programu. Blokování takového chování výrazně snižuje riziko šíření virů v systému.

Pro šíření virů je pochopitelně nutná existence hostitele, operačního systému nebo jiného druhu spustitelného prostředí, kterým může být například interpret příkazů, ve kterém se pak posloupnost znaků chová jako počítačový virus a dále se již replikuje rekurzivně.

Počítačové viry jsou automatizované programy, které se do nových cílů šíří proti vůli uživatele. Je však pravdou, že existují počítačové viry, které se před infekcí dalšího stroje zeptají uživatele například tímto způsobem:"Přejete si infikovat další program? (A/N?)". To je však nálepky viru nezbavuje. Často se setkávám s názorem výzkumníků-začátečníků, kteří se v takovém případě domnívají, že nejde o viry.

Pochopitelně se mýlí.

Při klasifikaci konkrétního programu jako viru je potřeba si položit důležitou otázku – zda-li je tento program schopen rekurzivního a explicitního šíření. Program nemůže být nazýván počítačovým virem, pokud ke svému šíření potřebuje cizí pomoc. Taková pomoc může být v podobě změny prostředí (například manuální změna bytů v paměti nebo na disku) nebo dokonce aplikace typu hot-fix zamýšleného viru za pomoci debuggeru! Naopak nefunkční viry by měly být klasifikovány jako zamýšlené viry.

Vzniklá kopie viru nemusí být nutně přesným klonem původního viru. Moderní počítačové viry, obzvláště pak tzv. metamorfické viry (dále probírány v kapitole 7) mohou přepsat svůj kód takovým způsobem, že úvodní sekvence bytů zodpovědná za šíření takového kódu je v následujících generacích zcela odlišná (při zachování stejné nebo alespoň podobné funkčnosti).

Kapitola 1 – Úvod do her přírody

40

Odkazy 1. Donald E. Knuth, The Art of Computer Programming, 2nd Edition, Addison-Wesley, Reading, MA, 1973, 1968, ISBN: 0-201-03809-9.

2. John von Neumann, "The General and Logical Theory of Automata," Hixon Symposium, 1948.

3. John von Neumann, "Theory and Organization of Complicated Automata", Lectures at the University of Illinois, 1949.

4. John von Neumann, "The Theory of Automata: Contruction, Reproduction, Homogenity", Nedokončený rukopis, 1953.

5. William Poundstone, Prisoner’s Dilemma, Doubleday, New York, ISBN: 0-385-41580-X, 1992.

6. Eli Bachmutsky, "Self-Replication Loops in Cellular Space", http://necsi.org:16080/postdocs/sayama/sdrs/java.

7. Robert A. Freitas, Jr. and William B. Zachary, "A Self-Replicating, Growing Lunar Factory", Fifth Princeton/AIAA Conference, květen 1981.

8. Robert A. Freitas, Jr., "Some Limits to Global Ecophagy by Biovorous Nanoreplicators, with Public Policy Recommendations", http://www.foresight.org/nanorev/ecophagy.html.

9. Gyorgy Marx, A Természet Játékai, Ifjúsági Lap és Konyvterjeszto Vállalat, Hungary, 1982, ISBN: 963-422-674-4.

10. Martin Gardner, "Mathematical Games: The Fantastic Combinations of John Conway’s New Solitaire Game ‘Life’", Scientific American, říjen 1970, strany 120-123.

11. Edwin Martin, "John Conway’s Game of Life", http://www.bitstorm.org/gameoflife (k dispozici je Java verze).

12. Carey Nachenberg, "Computer Virus-Antivirus Coevolution", Communications of the ACM, January 1997, Vol. 40, No. 1., strany 46-51.

13. Dewdney, A. K., The Armchair Universe: An Exploration of Computer Worlds, New York: W. H. Freeman (c), 1988, ISBN: 0-7167-1939-8.

14. Dewdney, A. K., The Magic Machine: A Handbook of Computer Sorcery, New York: W. H. Freeman (c), 1990, ISBN: 0-7167-2125-2, 0-7167-2144-9.

15. John Walker, "ANIMAL", http://fourmilab.ch/documents/univac/animal.html.

16. John Walker, "PERVADE", http://fourmillab.ch/documents/univac/pervade.html.

17. Rich Skrenta, http://www.skrenta.com.

18. John Shock and Jon Hepps, "The červ Programs, Early Experience with a Distributed Computation", ACM, Volume 25, 1982, strany 172-180.

19. Dr. Frederick B. Cohen, A Short Course on Computer Viry, Wiley Professonal Computing, New York, 2nd edition, 1994, ISBN: 0471007684.

20. Vesselin Vladimirov Bontchev, "Methodology of Computer Anti-Virus Research", University of Hamburg Dissertation, 1998.

KAPITOLA 2 Fascinující analýza škodlivého kódu "Lev se unaveně podíval na Alenku. ‘Jsi zvíře – nebo zelenina – nebo nerost?’ řekl, zívaje za každým slovem."

– Lewis Carroll (1832–1898), Alenka v říši divů za zrcadlem (1871).

42

Kapitola 2 – Fascinující analýza škodlivého kódu

Pro člověka se zájmem o přírodu je těžké najít něco více fascinujícího, než jsou počítačové viry. Analýza počítačových virů může na první pohled vypadat nesmírně složitě. Avšak tato složitost závisí pouze na konkrétním viru a jeho kódu. Binární podoba virů, kompilovaná z objektového kódu musí být pomocí reverzního inženýrství převedena do srozumitelnější podoby. Tento proces je pro jedince poměrně namáhavý, ale poskytne mu velké množství znalostí o fungování počítačových systémů.

Můj vlastní zájem o počítačové viry začal v září roku 1990 poté, co můj nový klon PC vypsal na obrazovku bizardní zprávu, po které následovaly dvě pípnutí. Zpráva zněla: "Your PC is now Stoned!"

O počítačových virech jsem již slyšel, ale toto bylo mé první setkání s těmito neuvěřitelnými potvůrkami na vlastní kůži. Byl jsem fascinován, jak rychle se na můj počítač virus dostal, protože jsem ho měl teprve dva týdny. Coby bootovací virus se ke mně dostal skrze infikovanou disketu s populární hrou jménem Jbird. Tuto hru jsem získal od svého přítele. Zjevně o skrytém "bonusu" skrývajícím se na disketě nevěděl.

V té době jsem samozřejmě neměl žádný antivirový program, a protože se tato událost stala v sobotu, žádná pomoc nebyla dostupná. Jistě si dovedete představit mé zklamání v případě PC klonu, který mě stál celých pět měsíčních platů. Bál jsem se totiž, že přijdu o všechna svá data na disku. Pamatoval jsem si na svého přítele, kterému se něco takového stalo v roce 1988 – jeho PC bylo infikováno virem, který vytvářet náhodně padající znaky na obrazovce a poté, po nějaké době, přestal počítač reagovat. Říkal, že musel formátovat harddisk a nainstalovat znovu všechny programy.

Později jsme zjistili, že jeho počítač byl infikován virem z rodiny Cascade. Tento virus bylo možné ze systému odstranit bez formátování disku, bohužel však nevěděl jak. Obzvlášť nepříjemný byl fakt, že přišel o všechna svá data. Samozřejmě – na svém stroji jsem chtěl přesný opak – odstranit virus, aniž bych přišel o svá data.

Ve snaze najít virus jsem nejprve prohledal soubory na disketě. Hledal jsem text, který jsem viděl na obrazovce. Naneštěstí jej však žádný ze souborů neobsahoval. Kdybych měl tehdy více zkušeností s hledáním virů, mohl bych zvažovat možnost, že virus byl v souborech zakódován. Ale virus zakódován nebyl a můj instinkt mě ohledně toho, kam by se mohl virus schovat, vedl správným směrem.

Došel jsem k názoru, že virus není uložen v souborech, ale někde jinde na disketě. Měl jsem k dispozici knihu Petera Nortona, Programmer's Guide to the IBM PC. Zatím jsem z ní přečetl jen pár stran, ale naštěstí zde byl uveden návod, jak se dostal k obsahu boot sektorů pomocí standardního nástroje systému DOS zvaného DEBUG. Po krátkém váhání jsem se konečně rozhodl poprvé v životě spustit příkaz DEBUG a s jeho pomocí jsem se pokusil prozkoumat boot sektor diskety, vložené do jednotky A. Příkaz byl následující: DEBUG -L 100 0 0 1

Tento příkaz instruoval DEBUG k tomu, aby nahrál první sektor (zaváděcí sektor) z jednotky A do paměti na offset 100 hexadecimálně. Poté, co jsem použil příkaz dump (D), jímž DEBUG zobrazí obsah nahraného sektoru, jsem uviděl zprávu, včetně dalšího textu.

-d280

Počítačové viry – analýza útoku a obrana

43

1437:0280 03 33 DB FE C1 CD 13 EB-C5 07 59 6F 75 72 20 50 .3........Your P 1437:0290 43 20 69 73 20 6E 6F 77-20 53 74 6F 6E 65 64 21 C is now Stoned!

1437:02A0 07 0D 0A 0A 00 4C 45 47-41 4C 49 53 45 20 4D 41 .....LEGALISE MA 1437:02B0 52 49 4A 55 41 4E 41 21-00 00 00 00 00 00 00 00 RIJUANA!........

Dovedete si jistě představit mé vzrušení z faktu, že jsem byl schopen najít počítačový virus. Konečně jsem ho měl přímo před sebou! Nad Nortonovou knihou jsem strávil celý zbytek víkendu, protože jsem kódu viru vůbec nerozuměl. Tehdy jsem ještě vůbec assembler pro IBM PC neznal, a bez toho jsem neměl šanci pochopit kód viru. Bylo toho tolik k učení!

Nortonova kniha mi poskytla značné množství informací, které jsem pro začátek potřeboval. Například mi poskytla skvělý popis bootovacího procesu, struktury disků, různých přerušení DOSu a základních rutin BIOSu. Analýzou viru Stoned jsem strávil mnoho dní tak, že jsem si na papír komentoval každou z instrukcí, dokud jsem neporozuměl všemu. Trvalo mi takřka celý týden, než jsem vstřebal všechny informace, ale můj počítač byl bohužel stále nakažen.

O několik dnů později jsem byl schopen v Turbo Pascalu vytvořit program na detekci a později i odstranění viru. Tento program byl schopen virus ze systému zcela odstranit – a to jak ze systémové paměti, tak i z boot a Master boot sektorů, kde se skrýval.

Za několik dnů jsem se svým detekčním programem navštívil univerzitu a zjistil, že se viru podařilo napadnout více než polovinu počítačů PC v laboratořích. Překvapilo mě, jakých úspěchů v šíření po celém světě může dosáhnout tak jednoduchý kus kódu. Jak se dostal z Nového Zélandu, odkud byl (jak jsem se dozvěděl později) na počátku roku 1988 vypuštěn až do Maďarska, kde infikoval můj počítač, už asi nikdo nezjistí.

Virus Stoned byl v oběhu. Autorství tohoto termínu se přičítá výzkumníku firmy IBM, Daveovi Chessovi, který takto popisuje viry, se kterými je možno se setkat mezi běžnými lidmi. A naopak – viry, které nikdy neopustí laboratoře výzkumníků (nebo sběratelů virů) nazýváme jako "zoo viry".

Lidé mou podporu ocenili a mě těšila možnost pomáhat a naučit se o virech ještě více. Začal jsem s pomocí přátel sbírat různé viry a vytvářet pro jednotlivé druhy dezinfekční programy. Mezi prvními, které jsem detailně analyzoval, byly viry jako Cascade, Vacsina, Yankee_Doodle, Vienna, Invader, Tequila a Dark_Avenger. Pro každý zvlášť jsem napsal detekční a dezinfekční program.

Má práce pak vyústila v diplomovou práci a moje antivirové programy distribuované jako shareware byly v Maďarsku hodně oblíbené. Svůj program jsem pojmenoval jako Pasteur (na počest francouzského mikrobiologa Louise Pasteura).

Všechno toto úsilí a zkušenosti mě jasně vedlo ke kariéře antivirového výzkumníka a vývojáře. Tato kniha je snahou o sdílení mých znalostí o výzkumu v oblasti počítačových virů.

2.1 Obvyklé vzorce výzkumu v oblasti virů Analýza počítačových virů obsahuje obvyklé vzorce, které je možné se snadno naučit a které vedou k větší efektivitě analýzy. Je několik technik, které výzkumníci obvykle používají při své cestě za cílem,

44

Kapitola 2 – Fascinující analýza škodlivého kódu

kterým je dokonalé porozumění virových zvyků v dostatečném předstihu, umožňujícím prevenci a zároveň odezvu zajišťující zvládnutí situace v případě, kdy daná hrozba propukne. Úkolem výzkumníků v oblasti virů je také identifikování a porozumění jednotlivých zranitelností, které jsou pak škodlivým kódem využívány. Tento výzkum zranitelností a exploitací má také své vlastní techniky a obvyklé vzorce. Některé z těchto technik jsou velmi podobné metodám zkoumání počítačových virů, jiné jsou naopak podstatně odlišné.

V této knize budete mít možnost poznat tyto užitečné techniky a naučíte se tak s virovými programy zacházet efektivněji. Kromě toho se naučíte, jak efektivně a bezpečně analyzovat počítačový virus za pomocí disassemblerů, debuggerů, emulátorů, virtuálních strojů, systémů určených k šíření virů, testovacích sítí pro viry, dekódovacích nástrojů a mnoha dalších užitečných pomůcek. Budete mít neustále možnost používat tyto informace k efektivnímu řešení problémů souvisejících s viry.

Dozvíte se také, jak se viry dělí do skupin a jak jsou pojmenovávány, stejně jako zajímavosti o nejpokročilejších virech.

Samotný kód počítačových virů v této knize rozebírán není. V mnoha zemích jsou podobné debaty nejenom neetické, ale také nezákonné1. Ještě důležitějším faktorem je však to, že ani autorství tuctu virů z vás neudělá odborníka v této oblasti. Někteří autoři počítačových virů2 si totiž o sobě myslí, že v okamžiku, kdy se jim podaří vytvořit kus kódu schopného vlastní replikace, se automaticky stávají odborníky v této oblasti.

Tato myšlenka je hodně daleko od pravdy. Ačkoliv se mezi tvůrci virů najdou opravdu zasvěcení jedinci, valná většina tvůrců vůbec nepatří mezi odborníky. Kapacity, které pravděpodobně ve své době představovaly vrchol umění tvorby počítačových virů, se skrývají (nebo skrývali) za nicky jako Dark Avenger3, Vecna, Jacky Qwerty, Murkry, Sandman, Quantum, Spanska, GriYo, Zombie, roy g biv nebo Mental Driller.

2.2 Vývoj antivirové obrany Původně nebyla tvorba antivirových programů nic složitého. V pozdních osmdesátých a počátkem devadesátých let bylo mnoho jedinců schopno vytvářet antivirové programy zaměřené na určitou formu počítačových virů.

Frederick Cohen dokázal, že antivirové programy nejsou schopny vyřešit problém počítačových virů definitivně, protože neexistuje způsob, jak by jediný program mohl být schopen se vypořádat se všemi viry, které vzniknou v budoucnosti. Bez ohledu na pravdivost tohoto tvrzení je však jisté, že se to už docela dlouho antivirům daří. Přestože jsou zkoumány a vznikají četné alternativy, jsou antiviry nejčastějším způsobem ochrany (a také obrany) proti virům a to i přes mnohé nevýhody, mezi které patří i zmiňovaná neschopnost vyřešit náš dříve uvedený problém.

Snad na základě mylného označení sebe sama za oborníka na počítačové viry mnoho bezpečnostních analytiků hlásá myšlenku, že antivirové programy jsou bezcenné v tu chvíli, kdy nejsou schopny detekovat zcela všechny hrozby, tedy i ze strany nejnovějších virů. Opak je ovšem pravdou a zmiňovaní analytici by se jistě sami přesvědčili o své chybě, kdyby zažili internet, který by bez existence antivirů prakticky stál na místě, neboť by byl zcela zahlcen provozem generovaným počítačovými viry.

Počítačové viry – analýza útoku a obrana

45

Často sami přesně nevíme, jak se máme proti virům bránit, a nevíme ani to, že je možné snížit riziko, které nám viry přinášejí, osvojením si správných hygienických návyků. Naneštěstí – neznalost a nedbalost jsou hlavními faktory podporujícími šíření počítačových virů. Sociologický aspekt počítačové bezpečnosti se zdá být důležitějším než aspekt technologický. Bezstarostné zanedbávání i nejzákladnější úrovně údržby počítače, nebezpečné nastavení sítě a neschopnost odstranit infekci v případě napadení – to všechno jsou faktory, které otevírají Pandořinu skříňku umožňující další šíření problémů na další systémy.

V raných fázích byl problém detekce a odstraňování virů snadno zvládnutelný, díky jejich malému počtu (v roce 1990 bylo známo pouhých 100 rodin virů). V té době se mohli výzkumníci zabývat celé týdny analýzou jednoho viru. V té době se navíc viry šířily podstatně pomaleji (na rozdíl od dnešní hektické doby). Typickým příkladem mohou být viry dlouhé 512 bajtů (velikost boot sektoru na IBM PC), kterým cesta do vedlejší země trvala třeba i celý rok. Čas, který potřebuje dnešní virus na své šíření oproti zmiňovaným virům z minulosti, si snadno představíte na příkladu rozdílu mezi rychlostí dnešní pošty oproti poště středověké, kdy byly zásilky dopravovány pěšky.

Nalézt virus v boot sektoru nebylo pro odborníka nic těžkého, napsat však program, který by to dokázal automaticky, už tak snadné nebylo. Ruční dezinfekce infikovaného systému bývala opravdovou výzvou už sama o sobě a představa programu, který by to dokázal sám, bylo považováno za děsivý úkol.

V současnosti je vývoj antivirů a bezpečnostního software považován za formu umění a vede jedince ke kultivaci a vytváření množství použitelných dovedností. Nicméně zvědavost, oddanost, tvrdá práce a nikdy nekončící touha se učit vede člověka k tomu, aby se z něj stal opravdový mistr tohoto uměleckého a tvořivého řemesla.

2.3 Terminologie škodlivých programů Potřeba definice jednotného názvosloví pro škodlivé programy je stará takřka jako samotné počítačové viry4. Je zřejmé, že každá klasifikace narazí na problémy, protože třídy se překrývají a jednotlivé třídy často představují vzdáleně příbuznou podtřídu každé jiné.

2.3.1 Viry V kapitole 1 je uvedena definice počítačového viru jako kódu5, který se rekurzivně šíří pomocí své změněné kopie nebo který šíří rovnou sám sebe. Viry na počítačích infikují soubory, nebo systémové prvky, nebo pozměňují odkazy na tyto objekty a poté, co převezmou kontrolu, se v dalších generacích opět množí.

2.3.2 Počítačoví červi Termín počítačový červ označuje síťové viry – tedy viry primárně se šířící sítěmi. Na vzdáleném počítači se obvykle spouštějí bez jakékoliv zásahu ze strany uživatele. Opačným případem jsou červi šířící se pomocí e-mailů, kteří pomoc uživatele potřebují.

Počítačový červ je obvykle samostatný program, který nepotřebuje hostitele. Někteří červi, jako například W32/Nimda.A@mm, používají metodu šíření infekcemi souborů jako vedlejší způsob svého roz-

46

Kapitola 2 – Fascinující analýza škodlivého kódu

šiřování, což je jasným ukazatelem toho, že nejsnadnější je červy považovat za podtřídu počítačových virů. Pokud se virus primárně šíří pomocí sítě, bude pokládán za červa.

2.3.2.1 Červi jednotlivě a hromadně rozesílající e-maily Červi, kteří jednotlivě nebo hromadně používají e-maily, tvoří zvláštní skupinu vorů, která se rozesílá společně s e-maily. Označení @mm (mass-mailer) v názvu viru označuje červa, který současně rozesílá velké množství e-mailů. Typickým příkladem může být například VBS/Loveletter.A@mm. Červi rozesílající e-maily jednotlivě, jako například W32/SKA.A@m (což je červ známý pod jménem Happy99) se pochopitelně rozšiřují s menší frekvencí. Již zmiňovaný červ Happy99 například vždy, tehdy, když uživatel posílá nový e-mail.

2.3.2.2 Chobotnice Chobotnice je sofistikovaný druh počítačového červa, který je tvořen sadou více programů rozmístěných na více než jednom počítači v síti.

Například, hlava a ocas takového programu jsou nainstalovány na různých počítačích a společně komunikujíce provádějí nějakou funkci. Chobotnice není příliš častá, nicméně v budoucnu se dá čekat větší rozšíření. Idea chobotnice má původ ve sci-fi novele Shockwave Rider od Johna Brunnera. Hrdina příběhu Nickie je na útěku a používá různé identity. Protože je odborník na telekomunikace, používá tzv. "tasemnice" k vymazávání svých dřívějších identit.

2.3.2.3 Králíci Králík je zvláštní druh počítačového červa, který v každém okamžiku existuje v jedné kopii, která "poskakuje" po sítěmi spojených hostitelských počítačích. Někteří výzkumníci používají tento termín k popisu škodlivých aplikací, které se rekurzivně spouští tak dlouho, dokud nezahltí paměť. V případě aplikací, které nejsou připraveny pracovat v prostředí s nízkými paměťovými zdroji, to může způsobit mnoho problémů.

2.3.3 Logické bomby Logická bomba je výraz pro naprogramovanou chybu běžného programu. Aplikace se například po určitém množství spuštění může sama smazat z disku jako součást schématu ochrany před kopírováním nebo mohou být naprogramovány další druhy škodlivého kódu, které se provedou po případném kopírování. Tyto scénáře jsou realistické v případech větších projektů s malým nebo limitovaným počtem revizí kódu.

Populární hra Mosquitos známá z mobilních telefonů Nokia série 60 je typickou ukázkou toho, jak vypadá výskyt této logické bomby v praxi. Tato hra obsahovala zabudovanou funkci, která odesílala SMS zprávy na zpoplatněné linky. První verze programu měly tuto funkci jako součást ochrany proti kopírování, resp. obecně proti softwarovému pirátství, bohužel však došlo k selhání6 a funkce se nechovala dle původních záměrů autorů. Proto byl tento kód z dalších verzí programu odstraněn (po mnoha stížnostech legitimních uživatelů). Zpoplatněné linky byly navíc deaktivovány. Pirátské verze programu

Počítačové viry – analýza útoku a obrana

47

obsahující tuto logickou bombu jsou však stále v oběhu a odesílají regulérní SMS zprávy. Hra používala telefonní čísla jako 4636, 9222, 33333 a 87140, které byly funkční ve čtyřech zemích. Například číslo 87140 odpovídalo Velké Británii. Hra po spuštění – a za použití těchto čísel – odeslala SMSku ve tvaru "king.001151183". Uživateli byla poté z kreditu odečtena příslušná částka.

Kód logické bomby je často ukryt mezi zdrojovými kódy daného programu – a takto schovaný stále setrvává. Častým případem skrytého kódu, který si najde cestu i do největších softwarových projektů, jsou takzvaná velikonoční vajíčka (easter eggs). Programátoři je vytvářejí například proto, aby v nich uvedli údaje o všech členech týmu pracujícímu na vývoji produktu.

Velikonoční vajíčka například obsahují některé části balíku Microsoft Office a mnohé velké vývojářské firmy je mají ve svých produktech rovněž zabudovány. A přestože nejsou tato konkrétní velikonoční vajíčka škodlivá a koncové uživatele vůbec neohrožují (ačkoliv mohou zabírat zbytečně prostor na disku), obecně jsou logické bomby škodlivé v každém případě.

2.3.4 Trojští koně Zřejmě nejjednodušším druhem škodlivého programu je trojský kůň. Takový program se snaží uživatele něčím zaujmout a vytvářet dojem "užitečnosti – aby uživatel neodolal a spustil jej na svém počítači.

V jiných případech hackeři přidávají k běžným programům nějakou dodatečnou funkčnost (trojského koně) jako kamufláž svých aktivit. Díky tomu pak mohou zpětně vypátrat daný systém a používat jej později.

Například na systémech UNIX hackeři často ponechávají upravenou verzi programu "ps" (nástroj zobrazující seznam procesů), která je modifikována takovým způsobem, aby se skrylo ID konkrétního procesu (PID), čímž je daný proces zamaskován před uživatelem. Na takto kompromitovaném systému je pak těžké vypátrat nějakou změnu. Útočník může totiž daný nástroj snadno modifikovat úpravou zdrojového kódu a takovou změnu je na první pohled takřka nemožné objevit.

Pravděpodobně nejznámějším trojským koněm je AIDS TROJAN DISK7, který byl na disketě odeslán zhruba na 7 000 adres výzkumných organizací po celém světě. Po svém zavedení do systému tento trojský kůň zpřeházel názvy všech souborů (kromě několika výjimek) a zcela zaplnil prázdné místo na disku. Obnovení dat bylo nabízeno za úplatu. Tímto se zrodil nový obor – škodlivá kryptografie. Autor tohoto trojského koně byl krátce po vypuknutí incidentu dopaden. Doktoru Josephovi Poppovi bylo tehdy 39 let, pracoval jako zoolog v Clevelandu ve státě Ohio a souzen byl ve Velké Británii8.

Funkce červa AIDS TROJAN DISK, která byla použita na zpřeházení jmen souborů, byla založena na dvou substitučních tabulkách9. Dříve byl tento postup10 považován za nenapadnutelný11. Ovšem na základě statistických metod (rozložení běžných slov) je tato šifra snadno napadnutelná. A navíc v případě, kdy má druhá strana dost času, může rozkladem kódu zjistit tyto tabulky přímo z nich.

Existují dva druhy trojských koňů: 

Sto procent kódu trojského koně je snadno analyzovatelného.



Pečlivá modifikace originálního programu s dodatečně přidanou funkčností, která patří do podtřídy zadních vrátek nebo sady pro administrátorský přístup. Tento typ je mnohem častější

48

Kapitola 2 – Fascinující analýza škodlivého kódu u open-source systémů, protože zde může útočník vložit funkce zadních vrátek do již existujícího kódu.

Poznámka Počátkem roku 2004 se dostaly do oběhu zdrojové kódy systému Windows NT a Windows 2000.

Očekává se proto, že budou vytvořeny zadní vrátka a sady pro root přístup, které toho využijí.

2.3.4.1 Zadní vrátka Zadní vrátka pro vzdálený přístup k systému jsou pro hackery nástrojem číslo jedna. Typický zástupce této skupiny po svém spuštění otevře síťový port (UDP/TCP) na daném počítači. Poté naslouchá a vyčkává na připojení útočníka, kterému umožní přístup do systému. Toto je nejčastější způsob fungování, který je často spojen s dalšími funkcemi z oblasti trojských koní.

Další typ, se kterým se setkáváme, je spojen se zneužitím návrhu. Některé aplikace, jako například již zmiňované prvotní implementace SMTP (což je protokol pro jednoduchou e-mailovou komunikaci) umožňovaly programům spouštět další programy – například pro řešení chyb. Příkladem může být internetový červ Morris, který používal určitý příkaz ke spuštění sebe samotného na vzdáleném systému. Tento příkaz byl umístěn jako příjemce zprávy. Krátce po uvedení tohoto červa byla tato funkčnost z mnoha programů odstraněna. Je však možné, že stále existují (a mohou existovat) programy s touto funkčností.

2.3.4.2 Trojští koně s funkcí hledání hesel Trojští koně kradoucí hesla jsou podtřídou trojských koňů. Jsou zaměřeni na hledání a odesílání hesel útočníkům. Poté se může útočník na daný systém kdykoliv připojit a pracovat na něm. Tyto programy jsou často kombinovány se zaznamenáváním stisků kláves na klávesnici (což je relativně snadný způsob získání hesla).

2.3.5 Zárodky Zárodky jsou první generace viru, která je ve formě neschopné svých běžných funkcí. Obvykle, když je virus poprvé zkompilován, existuje ve speciální podobě a nemá k sobě připojen hostitelský soubor.

Zárodky dále nemají obvyklé znaky virů druhé generace virů, které jsou používány k označení již infikovaných souborů (předchází se tím opětovné infekci).

Zárodek kódovaného nebo polymorfního viru je většinou nezakódovaný, jasný a čitelný kód. Detekce zárodků proto musí počítat se změnou strategie při jejich vyhledávání.

2.3.6 Exploity Exploitační kód je typický svým zaměřením na konkrétní zranitelnost nebo sadu zranitelností. Jeho cílem je automatické spuštění na (případně vzdáleném, síťovém) systému nebo poskytnutí jiného způ-

Počítačové viry – analýza útoku a obrana

49

sobu vysoce privilegovaného přístupu k cílovému systému. Je časté, že se útočník o svůj exploitační kód rozděluje s dalšími osobami. Tzv. "způsobní hackeři" vytvářejí exploitační kód pro otestování možnosti průniku pro vybraný systém. Škodlivost konkrétního exploitu je zřejmá až podle aktuálního způsobu použití – závisí tedy na úmyslu útočníka.

2.3.7 Stahovače Stahovač (downloader) je škodlivým programem, který instaluje nové programové položky na cíl útoku. Obvykle se do systému dostává jako příloha e-mailu a poté, co ho uživatel spustí (spuštění může být usnadněno nějakým exploitem), stahuje škodlivý obsah z webových stránek nebo jiné lokace a po rozpakování jej spustí.

2.3.8 Dialery Dialery se zrodily během doby, kdy začalo být vytáčené připojení (tzv. dial-up) široce dostupné domácnostem. Konceptem dialerů je donutit – často nic netušícího – uživatele, aby platil za použití telefonních linek se speciálním cenovým tarifem (obvykle dost vysokým). Často se vyskytují v případě tzv. porn dialerů, kdy je sice uživatel informován o tom, že pro spojení bude používáno jiné telefonní číslo, ale už neví nic o budoucích následcích ohledně ceny. Podobný přístup existuje u webových stránek odkazujících uživatele na placené služby.

2.3.9 Droppery Původ termínu odkazuje na "instalátory" pro první generace virů. Například boot viry, které existují jako zkompilované soubory v binární podobě, jsou často pomocí dropperu umístěny do boot sektorů.

Virus takto začíná žít vlastním životem a šíří se bez potřeby dropperu.

Pokud virus funkci dropperu během své infekční cesty obnoví, je třeba i dropper považovat za součást infekčního cyklu a neměl by se zaměňovat za původní vyhrazený druh dropperu.

2.3.10 Injektory Injektory jsou zvláštním druhem dropperů, které obvykle do paměti počítače instalují kód viru. Injektor může být tímto způsobem použit pro vložení funkčního kódu viru na ovladač přerušení disku. Poté, co uživatel k disketě přistoupí běžným způsobem, začne se virus šířit.

Zvláštním druhem injektoru je síťový injektor. Za použití legitimních pomůcek, jako například NetCat (NC), injektují kód po síti. Datagram se obvykle pošle na specifikované místo v síti. Použití může vypadat třeba tak, že útočník vloží pomocí injektoru červa – ten se pak následně šíří pomocí sítě ve formě dat, bez toho aniž by se znovu dotknul disku.

Injektory jsou často použity k procesu nazvaného jako rozsévání (seeding). Rozsévání je proces, při kterém je do velkého množství systémů vložen injektorem virus. Díky tomu může náhle propuknout velká epidemie. Existují důkazy, že tímto způsobem byl z mnoha systémů najednou12 rozšiřován červ W32/Witty.

50

Kapitola 2 – Fascinující analýza škodlivého kódu

2.3.11 Auto-Rootery Auto-rooter je pomůcka obvykle určená hackerům s úmyslem škodit a je používána pro získávání přístupu do nových systémů pomocí průniku do nich. Obvykle se jedná o sadu exploitů, které se spouštějí proti nějakému cíli takovým způsobem, aby bylo útočníkovi umožněno získat administrátorská práva.

Většinou jsou to skripty určené pro hackery-začátečníky.

2.3.12 Kity (generátory virů) Autoři virů často vytvářejí různé kity (ve stylu Virus Creation Laboratory nebo PSMPC), které umožnují podle voleb uživatele automaticky generovat nové viry. Takto mají možnost tvořit škodlivé počítačové viry i nováčci bez větších odborných znalostí. Některé generátory umí produkovat většinu typů virů, včetně virů Win32. V kapitole 7 je zmíněn virus nazvaný jako "Anna Kournikova" (technicky se jedná o VBS/VBSWG.J), který byl vytvořen holandským teenagerem Janem de Witem pomocí kitu VBSWG – bohužel, de Wit měl "štěstí" a kit proslulý vytvářením nefunkčních virů vytvořil fungující virus. Proč bohužel? De Wit byl totiž následně zatčen, usvědčen a odsouzen za svou část viny v tomto případě.

2.3.13 Programy pro spam Vikingové: Spam spam spam spam Číšnice: C9spam spam spam vejce a spam; spam spam spam spam spam vařené fazole spam spam spamC9 Vikingové: Spam! Lahodný spam! Miloučký spam!

– Spam Song od skupiny Monty Python Tyto programy jsou použity pro šíření nevyžádaných zpráv skupinám uživatelům pomocí e-mailů, SMS zpráv či zpráv určených pro různé komunikační programy (ICQ atd.).

U zrodu mezinárodní popularity spamu stáli dva právníci, kteří z něj udělali superstar internetové virové scény. Jejich hlavním cílem bylo odesílání spamu do internetových diskusních konferencí. Spam se postupem času stal hlavní nepříjemností internetu. Mnoho uživatelů e-mailu si stěžuje na to, že spam tvoří až 70 procent jejich příchozí pošty denně. Toto procento se v poslední době zvyšuje.

Základním motivem každého spammera je získání peněz generováním provozu. Spamy jsou navíc často použity k podpoře tzv. phishingu. Proto například můžete obdržet e-mailovou zprávu, která vás žádá k návštěvě webových stránek banky, kterou používáte a tvrdí, že pokud tak neučiníte, bude váš účet zrušen. Ve zprávě je uveden odkaz, který však vede na stránky podvodníků, které se tváří jako oficiální stránky banky. Pokud podlehnete, je jisté, že útočníkovi sdělujete svá osobní data na stříbrném podnose.

Podvodník by totiž například rád získal číslo vašeho bankovního účtu, číslo kreditní karty, heslo, PIN a další osobní informace. Tyto informace se pak dají použít k získání vašich peněz. Někdy se dokonce může stát, že vám bude pomocí těchto informací ukradena vaše identita (identity theft).

Počítačové viry – analýza útoku a obrana

51

2.3.14 Floodery Tyto programy jsou používány hackery pro útoky na síťové počítačové systémy – pomocí nich se generuje nadměrný síťový provoz, což vede k DoS, což je útok odmítnutím služby. Pokud je takový útok veden z mnoha napadených systémů (tzv. zombie stroje) současně, nazýváme jej distribuovaným DoS útokem (DDoS). Existuje mnoho sofistikovaných typů DoS útoků, včetně SYN flooderů, útoků založených na fragmentaci paketů, zesílení provozu, odražení provozu, útoky na uspořádání provozu, pokud chceme jmenovat alespoň ty nejvíce obvyklé typy.

2.3.15 Snímače stisku kláves Tyto programy snímají na napadeném počítači stisknuté klávesy a předávají tyto informace útočníkům.

Tyto informace mohou obsahovat různé citlivé informace jako například jména, hesla, PINy, data narození, čísla kreditních karet atd. Snímací program je nainstalován na počítači (bez vědomí uživatele) a může trvat týdny a týdny, než si postižený vůbec útoku všimne. Získaná data bývají útočníky často zneužita ke krádežím identity (identity theft).

2.3.16 Rootkity Rootkit je speciální sada hackerských pomůcek, které jsou používány hackery poté, co získají přístup k systému (včetně administrátorských práv). Obvykle se hacker prolomí do systému za pomoci nějakých exploitů a nainstaluje modifikované verze běžných nástrojů. Takové rootkity jsou nazývány jako rootkity uživatelského režimu (user-mode rootkits), protože tyto "trojanizované" aplikace běží v uživatelském režimu.

Některé sofistikovanější rootkity, kterým je například Adore13 mají nainstalovány komponenty modulů jádra. Tyto rootkity jsou nebezpečné, neboť pozměňují chování jádra. Mohou tak skrývat procesy, soubory v souborovém systému, klíče registrů a hodnot systému Windows nebo implementovat možnosti skrytého běhu pro další škodlivé komponenty. Rootkity uživatelského režimu se naopak neumí příliš efektivně schovávat před ochranným softwarem založeným na úrovni jádra. Rootkity uživatelského režimu pouze manipulují s objekty v uživatelském režimu, a proto mají systémy ochrany na úrovni jádra šanci je odhalit.

2.4 Další kategorie Tato kategorie internetových škůdců, se kterými se můžeme setkat, nemusí být záměrně škodlivá. Přesto však působí nepříjemnosti koncovým uživatelům, a proto rovněž existují antivirové a antispamové prostředky k odstranění těchto problémů.

2.4.1 Zábavné programy Tyto programy nebývají škodlivé – ale i tak platí věta Alana Solomona (autora jednoho z nejrozšířenějších antivirových skenerů dneška), která zní takto: "Zda-li má být program klasifikován jako zábavný program nebo trojský kůň, velmi závisí na smyslu pro humor napadeného uživatele". Zábavné programy mění nebo přerušují běžné chování vašeho počítače a celkově tak působí nepříjemným nebo rušivým způsobem. Kolegové z práce si často dělají legraci z jiných instalacemi těchto programů a snahou do-

52

Kapitola 2 – Fascinující analýza škodlivého kódu

nutit ostatní k jejich spuštění. Typickým případem zábavného programu je spořič obrazovky, který náhodně zablokovává systém.

Avšak i tyto programy dokáží být škodlivé. Zvažte použití zábavného programu, který systém zablokuje, ale už neodblokuje. Důsledkem je, že počítač nelze bezpečně vypnout a uživatel tak může přijít o data, která se nestihla uložit na disk nebo může dokonce dojít k poškození alokační tabulky souborů – operační systém už nenaběhne.

2.4.2 Poplašné zprávy: řetězové dopisy Poplašné zprávy obvykle šíří zprávu o hrozící počítačové infekci a prosí příjemce, aby zprávu předal ostatním uživatelům. Jedna z nejznámějších poplašných zpráv byla fáma o viru Good times. Fáma se poprvé objevila v roce 1994 a informovala uživatele o možnosti napadení novým virem, který může dorazit v e-mailu. Zpráva prohlašovala, že přečtení zprávy obsahující řetězec "Good times" v předmětu e-mailu povede ke smazání dat na disku. Přestože se však mnozí domnívali, že podobná možnost je čistě fiktivní, je pravdou, že podobná možnost payloadu existuje. Poplašné zprávy většinou pracují s mixem reality a lži. Tato fáma tvrdila, že takový virus existuje, což je zjevně nepravdivé.

Koncoví uživatelé pak šíří takové zprávy dalším lidem a zatěžují jim tak e-mailové klienty. Ve větších firmách musely být dokonce uvedeny v činnost příslušné směrnice zabraňující šíření podobných zpráv po lokálních sítích. V minulosti například cirkulovala velkými korporacemi zpráva snažící se přesvědčit uživatele o pravdivosti příběhu o velmi nemocném dítěti a snažící se posbírat finance na nákladnou operaci. Většina uživatelů je solidárních a neuvědomují si následky předávání takových zpráv – důvěřují zdroji a smyšlenému příběhu.

Pokud se ve firmách používají a dodržují příslušné směrnice, mohou být následky podobných zpráv eliminovány. Přesto jsou každoročně takové zprávy považovány za nejúspěšnější z internetových hrozeb – příkladem určitě budou zcela nové řetězové dopisy rychle se šířící celým světem.

2.4.3 Další hmyz: adware a spyware Nový druh aplikace, která je přímým důsledkem rozšiřování počtu domácností připojených k internetu.

Mnohé firmy se zajímají o to, na co se lidé na internetu dívají a co hledají. A obzvláště se zajímají o to, jaké druhy výrobků si lidé kupují. Proto také některé firmy zabývající se koncovým prodejem nabízejí k instalaci malé aplikace, které sbírají informace a zobrazují uživatelům přesně cílenou reklamu.

Problémem tohoto druhu aplikací je to, že nejsou psány s úmyslem škodit. Vytvářejí je programátoři, kteří si tímto způsobem vydělávají na živobytí. Ovšem mnohé příklady aplikací nainstalovaných bez vědomí uživatele jistě představují celou vlnu otázek ohledně soukromí. Není proto překvapením, že jak firmy, tak ani samotní uživatelé si tento druh programů příliš neoblíbili. Obzvláště pak druh programů pojmenovaný termínem spyware, který sbírá informace o uživateli a odesílá je firmám přes internet.

Domácí uživatelé jsou neoddiskutovatelně rušeni útočnou povahou a to ani nezmiňujeme frustraci, kterou uživatelé cítí při pohledu na vyskakující okna prohlížeče s cílenou reklamou. Často se navíc stává, že programy jsou napsány špatným způsobem a spotřebovávají velké množství systémových prostředků, zejména v případech, kdy jej jich na počítači nainstalováno větší množství. Mají

Počítačové viry – analýza útoku a obrana

53

také velmi nepříjemný zvyk snižovat úroveň zabezpečení programu Internet Explorer až k bezvědomí a vystavují tak oběť (často nic netušící) možnosti ještě horší infekce14.

Protože jsou tyto aplikace často hlavním zdrojem příjmů různých internetových obchodů, je v jejich zájmu, aby antivirové prostředky tyto programy nedetekovaly vůbec, nebo aby je nedetekovaly při obvyklých nastaveních. Je častým jevem, že podobné firmy si najímají právníky, aby bojovali proti výrobcům produkujícím programy, které jejich "aplikace" detekují a následně odstraňují. To pochopitelně boj proti tomuto druhu hmyzu ještě více znesnadňuje.

Dá se však očekávat, že podobné programy budou v budoucnu v mnoha státech zakázány. Aby vše bylo ještě zajímavější, některé firmy si na jedné přejí, aby byly odstraněny "nechtěné" zdroje spyware, ale naopak, na druhé straně přejí, aby byly ponechány jejich "nástroje" určené k regulérnímu špehování jejich zaměstnanců.

2.5 Schéma pojmenování počítačových škodlivých programů Zakládající členové organizace CARO (organizace počítačových antivirových výzkumníků) počátkem roku 1991 vytvořili schéma pojmenovávání15 počítačových virů pro použití v antivirových (AV) produktech. Schéma organizace CARO je v porovnání s dnešní praxí poněkud zastaralé, ale zůstává jediným pokusem o adaptování standardu. Aktualizovaná verze dokumentů je ve vývoji a očekává se, že bude brzy publikována na stránkách www.caro.org. V této sekci vám mohu poskytnout pouze pohled z výšky tří kilometrů na problematiku pojmenovávání malwaru. Pro další rozšíření vašich informací mohu doporučit zápis Nicka FitzGeralda z konference AVAR 200216. Dále je potřeba zmínit dík všem respektovaným antivirovým výzkumníkům v CARO.

Poznámka Původní schéma názvů pochází od Dr. Alana Solomona, Fridrika Skulasona a Dr. Vesselina Bontcheva.

Pojmenovávání virů je výzvou pro každého výzkumníka. Naneštěstí jsme dnes svědky velkého zvýšení počtu rychle se šířících virů s velkým záběrem napadených strojů. V současnosti přibývá měsíčně 500 až 1500 nebo dokonce ještě více nových hrozeb. Proto se pojmenovávání počítačových virů – a to i v případě stejného typu viru – stává těžkým, resp. neřešitelným problémem. Přesto se představitelé antivirových firem snaží předcházet zmatku používáním běžných jmen, alespoň v případech nejčastěji se vyskytujících škodlivých programů. Výzkumníci se však (díky rychlému nárůstu infekce) nemusí na jménu stačit dohodnout a raději rychle vytvářejí definice k odstranění hrozby. Ještě častějším problémem se stává predikce toho, který virus se rozšíří a který zůstane zoo virem.

Mnoho lidí má lepší vybavovací schopnost pro textová jména rodin nežli "holá" číselná ID nebo jiná identifikační schémata vynořující se v prostoru počítačové bezpečnosti. Podívejme se na pojmenovávání škodlivých programů v jeho nejkomplexnější podobě: <malware_type>://<platform>/<family_name>.<group_name>.<infective_length>.<va riant><devolution><modifiers>

54

Kapitola 2 – Fascinující analýza škodlivého kódu

Český překlad tohoto schéma vypadá následovně (bude používán dále v knize): <typ_škodlivého_programu>://<platforma>/<jméno_rodiny>.<jméno skupiny>.<infekční_délka>.<varianta><převod><modifikátory>

V praxi jen velmi málo škodlivých programů (pokud vůbec nějaké) vyžaduje použití všech kolonek. Dá se říci, že prakticky vše kromě políčka <jméno_rodiny> je volitelné: [<typ_škodlivého_programu>://][<platforma>/]<jméno_rodiny >[.< jméno skupiny>][.<infekční_délka >][.<varianta>[<převod>]][<modifikátory>]

Následující části knihy krátce popíší každou komponentu pojmenovávání škodlivého programu.

2.5.1 <jméno_rodiny> Toto je klíčová část systému pro pojmenování škodlivého softwaru. Základní pravidla pro vytvoření jména rodiny jsou následující: 

Nesmí se používat názvy firem, značky nebo jména žijících lidí.



Nesmí se použít jméno již existující rodiny, pokud do ní virus jednoznačně nepatří.



Nesmí se používat sprostá nebo nepřístojná slova.



Nesmí se používat další jméno rodiny, pokud již existuje. Použijte nástroj typu VGrep pro zjištění křížových vazeb mezi staršími škodlivými programy.



Nesmí se používat jména složená pouze z čísel.



Vyhněte se domnělému nebo zamýšlenému jménu autora.



Vyhněte se pojmenování škodlivého programu po souboru, který ve většině případech obsahuje škodlivý kód.



Vyhněte se pojmenování rodin stylem pátek_13tého (friday_13th), zejména v případech, kdy toto datum představuje spouštěč payloadu.



Vyhněte se pojmenování dle geografických lokací založených na místech nálezu.



Pokud existuje více akceptovatelných názvů, vyberte původní jméno, jméno používané většinou existujících antivirových programů nebo nejvýstižnějším z nich.

2.5.2 <typ_škodlivého_programu>:// Tato část jména specifikuje, zdali se jedná o virus, trojského koně, dropper, kit nebo odpad (Virus://, Trojan://, Garbage://). Mnohé produkty mají toto pole lehce rozšířené a v budoucnu se očekává rozšíření standardu jejich směrem.

2.5.3 <platforma>/ Prefix platformy specifikuje minimální nativní prostředí nutné pro korektní funkčnost daného škodlivého programu. Seznam všech oficiálně rozpoznávaných platforem, včetně popisků, je uveden v další sekci.

Počítačové viry – analýza útoku a obrana

55

Poznámka Pro jednu určitou hrozbu může existovat více napadnutelných platforem. V takovém případě může být použito více jmen – například virus://{ W32,W97M} /Beast.41472.A17. Tato definice znamená, že virus pojmenovaný jako Beast je schopen infekce nejenom na platformě Win32, ale je navíc schopen infikovat dokumenty programu Microsoft Word 97.

2.5.4 <jméno_skupiny> Jméno skupiny popisuje větší rodinu počítačových virů, jejíž členové si jsou vzájemně podobni. Dnes už se příliš nepoužívá. Bývá spojováno především s potřebou seskupování virů pro DOS.

2.5.5 <infekční_délka> Infekční délka je používána pro rozlišení mezi parazitickými viry uvnitř rodiny, nebo skupiny na základě jejich obvyklé délky v bytech.

2.5.6 <varianta> Tato podproměnná pomáhá rozlišit drobné změny v jednotlivých verzích virů patřících do stejné rodiny a majících stejnou infekční délkou.

2.5.7 [<<převod >] Identifikátor převodu je nejběžněji uváděn se jménem pod-varianty v případě makrovirů. Některé makroviry mají vlastnost (obvykle způsobenou špatným naprogramováním) vytvářet, v průběhu svého běžného množení, pod-sady své originální sady maker. Takto vytvořené pod-sady nemají možnost obnovy originální sady maker, ale jsou dále schopny se rekurzivně replikovat ze své částečné sady.

2.5.8 <modifikátory> Původním úmyslem modifikátoru byla identifikace polymorfismu počítačových virů. Dodnes však nebyl antivirovými výzkumníky v praxi použit. Modifikátor v současnosti obsahuje následující řadu komponent: [[:<specifikátor_lokace>][#<způsob_komprimace>][@‘m‘|‘mm‘][!<výrobcespeciální_komentář>]]

2.5.9 :<specifikátor_lokace> Tento specifikátor je používán hlavně pro makroviry, které jsou závislé na verzi svého prostředí, který může být například program Word. Proto například specifikátor virus://WM/Concept.B:Fr označuje virus, který napadá pouze francouzskou verzi programu Microsoft Word.

56

Kapitola 2 – Fascinující analýza škodlivého kódu

2.5.10 #<způsob_komprimace> Tento modifikátor je v praxi používán minimálně. Může indikovat to, že škodlivý program byl zabalen nebo "za běhu" rozbalen nějakým programem (např. UPX).

2.5.11 @m nebo @mm Tyto symboly označují samostatně nebo masově se šířící druh počítačových virů, používajících e-mail pro své šíření. Navržen Bontchevem je tento modifikátor jedním z nejrozšířenějších vůbec. Díky tomu je také jasné, že se s nimi veřejnost (díky způsobu šíření) setká nejčastěji.

2.5.12 !<výrobce_speciální komentář > Modifikátor určený pro zvláštní komentář je novinkou k sadě modifikátorů. Výrobci mají možnost u jakéhokoliv škodlivého programu doplnit modifikátor k jeho jménu. Například – výrobce může chtít uvést, že se jedná o virus složený z více částí (multipartite) a tak přidá ke jménu !mp.

2.6 Komentovaný seznam oficiálně rozpoznávaných platforem Názvy platforem uvedené v tabulce 2.1 jsou jedinými oficiálně uznávanými identifikátory. Jméno platformy, které není uvedeno na tomto seznamu, nemůže být použito jako identifikátor ve jménu škodlivého kódu řídícím se těmito standardy. Pro drobnější odlišení jmen platforem je určena položka komentářů. V době vydání knihy je toto uznávaným autorizovaným seznamem. Seznam platforem bude v budoucnu rozšiřován.

Tabulka 2.1 – Oficiální seznam rozpoznávaných platforem.

Krátká forma

Dlouhá forma

Komentáře

ABAP

ABAP

Škodlivý kód pro aplikační programovací prostředí SAP /R3 Business Application Programming.

ALS

ACADLispScript

Škodlivý kód vyžadující interpret AutoCAD Lisp.

BA

BAT

Škodlivý kód vyžadující příkazovou řádku DOSu nebo Windows prostředí nebo její klon.

BeOS

BeOS

Vyžaduje BeOS.

Boot

Boot

Vyžaduje MBR nebo systémový boot sektor IBM PC–kompatibilního harddisku nebo diskety. (V praxi užívané zřídka)

DOS

DOS

Infikuje DOS COM a/nebo EXE (MZ) nebo SYS formáty souborů a vyžaduje určité verze MS-DOSu nebo prostředí blízce kompatibilního OS. (V praxi užívané zřídka)

EPOC

EPOC

Vyžaduje EPOC OS do verze 5.

SymbOS

SymbianOS

Vyžaduje Symbian OS (EPOC verze 6 a novější).

Počítačové viry – analýza útoku a obrana

57

Krátká forma

Dlouhá forma

Komentáře

Java

Java

Vyžaduje spouštěcí prostředí Java (buď samostatné či vložené v prohlížeči)

MacOS

MacOS

Vyžaduje Macintosh OS nižší než OS X.

MeOS

MenuetOS

Vyžaduje MenuetOS.

MSIL

MSIL

Vyžaduje spouštěcí prostředí jazyka Microsoft Intermediate.

Mul

Multi

Tato pseudo-platforma je vyhrazena pro velmi speciální případy.

PalmOS

PalmOS

Vyžaduje verzi PalmOS.

OS2

OS2

Vyžaduje OS/2.

OSX

OSX

Vyžaduje Macintosh OS X nebo podobnou verzi.

W16

Win16

Vyžaduje některou z verzí 16bitových Windows.

W95

Win95

Vyžaduje služby VxD Windows 9x.

W32

Win32

Vyžaduje 32bitové Windows (Windows 9x, ME, NT, 2000 a XP na platformě x86).

W64

Win64

Vyžaduje Windows 64.

WinCE

WinCE

Vyžaduje WinCE.

WM

WordMacr

Škodlivý makro-kód pro WordBasic, který byl obsažen v programech WinWord 6.0, Word 95 a Word pro Mac 5.x.

W2M

Word2Macro

Škodlivý makro-kód pro WordBasic, který byl obsažen v programu WinWord 2.0.

W97M

Word97Macro

Škodlivý makro-kód pro Visual Basic pro aplikace (VBA) v5.0 pro Word (vydané společně s Word 97) nebo pozdější. Změny VBA mezi verzemi Word 97 a 2003 (včetně) jsou natolik malé, že jednotlivé platformy nejsou rozlišovány.

AM

AccessMacro

Škodlivý makro-kód pro AccessBasic.

A97M

Access97Macro

Škodlivý makro-kód pro Visual Basic pro aplikace (VBA) v5.0 pro Access vydané společně s Access 97 a pozdějšími. Stejně jako u W97M jsou změny mezi VBA verzemi pro Access 97 a 2003 (včetně) příliš malé pro rozdělení platforem.

P98M

Project98Macro

Škodlivý makro-kód pro Visual Basic pro aplikace (VBA) v5.0 pro Project vydaný společně s Project 98 a pozdější. Stejně jako u W97M jsou změny mezi VBA verzemi pro Project 98 a 2003 (včetně) příliš malé pro rozdělení platforem.

58

Kapitola 2 – Fascinující analýza škodlivého kódu

Krátká forma

Dlouhá forma

Komentáře

PP97M

PowerPoint97Macro

Škodlivý makro-kód pro Visual Basic pro aplikace (VBA) v5.0 pro Project, vydaný společně s in Project 97 a novější. Stejně jako u W97M jsou změny mezi VBA verzemi pro Project 97 a 2002 (včetně) příliš malé pro rozdělení platforem.

V5M

Visio5Macro

Škodlivý makro-kód pro Visual Basic pro aplikace (VBA) v5.0 pro Visio vydané společně s Visio 5.0 a pozdější verze. Stejně jako u W97M jsou změny mezi VBA verzemi pro Visio 5.0 a 2002 (včetně) příliš malé pro rozdělení platforem.

XF

ExcelFormula

Škodlivý program založený na "rovnicovém" jazyku Excel vydaném společně s ranou verzí Excelu.

XM

ExcelMacro

Škodlivý makro-kód pro Visual Basic aplikace (VBA) v3.0 vydané společně s Excelem pro Windows 5.0 a Excelem pro Mac 5.x.

X97M

Excel97Macro

Škodlivý makro-kód pro Visual Basic pro aplikace (VBA) v5.0 pro Excel vydaný společně s Excelem 97 a pozdějším. Stejně jako u W97M jsou změny mezi VBA verzemi pro Excel 97 a 2002 (včetně) příliš malé pro rozdělení platforem.

O97M

Office97Macro

Toto je psudo-jméno platformy rezervované pro škodlivý makro-kód infikující alespoň dvě a více aplikace v Office 97 a novějších verzích. Křížově propojené infektory mezi aplikacemi produktů Office jako Project či Visio mohou být takto rovněž pojmenovány.

AC14M

AutoCAD14Macro

VBA v5.0 makro viry pro AutoCAD r14 a novější. Stejně jako u škodlivého kódu W97M, jsou změny v novějších verzích příliš malé pro rozdělení platforem.

ActnS

ActionScript

Vyžaduje intepret ActionScriptu od Macromedia, který obvyklý v některých přehrávačích animací založených na flashi.

AplS

AppleScript

Vyžaduje interpret AppleScriptu.

APM

AmiProMacro

Škodlivý makro-kód pro AmiPro.

CSC

CorelScript

Škodlivý kód vyžadující interpret CorelScript dostupný v mnoha produktech od Corelu.

HLP

WinHelpScript

Vyžaduje interpret skriptů pro WinHelp.

INF

INFScript

Vyžaduje jeden z interpretů skriptů Windows INF (instalátor).

Počítačové viry – analýza útoku a obrana

59

Krátká forma

Dlouhá forma

Komentáře

JS

JScript, JavaScript

Vyžaduje interpreta JScriptu nebo JavaScriptu. Hostování neovlivňuje platformu – samostatný škodlivý kód JS, kód vyžadující MS JS pod WSH, škodlivý kód JS vložený do HTML a škodlivý kód JS vložený do kompilovaných HTML souborech nápovědy (CHM) pro WIndows. To všechno patří pod tento typ platformy.

MIRC

mIRCScrip

Vyžaduje interpret skriptů mIRC.

MPB

MapBasic

Vyžaduje MapBasic produktu MapInfo.

Perl

Per

Vyžaduje interpret Perlu. Hostování neovlivňuje platformu – samostatné Perl infektory pro UNIX prostředí nebo jiné vyžadující Perl pod WSH a škodlivý kód Perlu v HTML. To všechno patří pod tento typ platformy.

PHP

PHPScript

Vyžaduje interpret skriptů PHP.

Pirch

PirchScript

Vyžaduje interpret skriptů Pirch.

PS

PostScript

Vyžaduje interpret skriptů PostScript.

REG

Registry

Vyžaduje interpret souborů registrů Windows. (Nerozlišujeme mezi .REG verzemi nebo ASCII verzemi dle unicode.)

SH

ShellScript

Vyžaduje interpret skriptů UNIX (nebo podobný). Hostování neovlivňuje jméno platformy – škodlivý kód specifický pro Linux, Solaris, HP-UX, nebo další systémy, nebo specifický pro csh, ksh, bash, nebo jiný interpret současnosti. To všechno spadá pod tuto platformu.

VBS

VBScript

Vyžaduje interpret VBS. Hostování neovlivňuje platformu – samostatný VBS infektor, infektor vyžadující VBS pod WSH, škodlivý kód VBS vložený do HTML, škodlivý kód vkládaný do zkompilovaných HTML souborů nápovědy (.CHM) pro Windows. To všechno dnes spadá pod tuto platformu.

UNIX

UNIX

Běžné jméno pro binární viry pro platformu UNIX. (Jsou k dispozici i přesnější jména platforem.)

BSD

BSD

Použit pro škodlivý kód typický pro BSD platformy (nebo z něj odvozené).

Linux

Linux

Použit pro škodlivý kód typický pro Linux platformy (nebo z něj odvozené).

Solaris

Solaris

Použit pro škodlivý kód typický pro Solaris.

Kapitola 2 – Fascinující analýza škodlivého kódu

60

Odkazy 1. Joe Hirst, "Virus Research and Social Responsibility", Virus Bulletin, říjen 1989, strana 3.

2. Sarah Gordon, "The Generic Virus Writer", Virus Bulletin Conference, 1994.

3. Vesselin Bontchev, "The Bulgarian and Soviet Virus Writing Factories", Virus Bulletin Conference, 1991, str. 11-25.

4. Dr. Keith Jackson, "Nomenclature for Malicious Programs", Virus Bulletin, březen 1990, strana 13.

5. Vesselin Bontchev, "Are ‘Good’ Computer Viry Still a Bad Idea?", EICAR, 1994, str. 25-47.

6. Jamo Niemela, "Mquito", http://www.f-secure.com/v-descs/mquito.shtml.

7. Jim Bates, "Trojan Horse: AIDS Information Introductory Diskette Version 2.0", Virus Bulletin, leden 1990, strana 3.

8. Mark Hamilton, "U.S. Judge Rules In Favour Of Extradition", Virus Bulletin, leden, 1991.

9. Istvan Farmosi, Janos Kis, Imre Szegedi, "Viruslelektan", Alaplap Konyvek, Budapešť, 1990, ISBN: 963-02-8675-0.

10. David Kahn, "The CODE-Breakers", Scribner, New York, 1967, 1996, ISBN: 0-684-83130-9.

11. Tibor Nemetz, Istvan Vajda, "Algorithmic Cryptography", Academic Press, Budapešť, 1991, ISBN: 963-05-6093-2.

12. Peter Ferrie, Frederic Perriot and Peter Szor, "Chiba Witty Blues", Virus Bulletin, květen 2004, str.

9-10.

13. Sami Rautiainen, "Hidden Under the Hood: Linux Backdoors", Virus Bulletin Conference 2002, str. 217-234.

14. Nick FitzGerald, soukromá komunikace, 2004.

15. Vesselin Bontchev, Fridrik Skulason and Alan Solomon, "A Virus Naming Convention", přístupné na FTP serveru Hamburské university, ftp://ftp.informatik.uni-hamburg.de/pub/ virus/texts/tests/naming.zip.

16. Nick FitzGerald, "A Virus by Any Other Name: The Revised CARO Naming Convention", AVAR Conference, 2002.

17. Peter Szor, "Beast Regards", Virus Bulletin, červen 1999, str. 6-7.

KAPITOLA 3 Prostředí škodlivého kódu

"Je něco zázračného ve všech výtvorech přírody."

– Aristoteles

62

Kapitola 3 – Prostředí škodlivého kódu

Jedním z nejdůležitějších kroků pro pochopení počítačových virů je především dobré pochopení prostředí, ve kterém operují. Teoreticky je jistě možné pro jakoukoliv sekvenci znaků definovat prostředí, ve kterém se tato sekvence bude schopna replikovat. V praxi je však potřeba najít prostředí, ve kterém tato sekvence funguje a dokázat, že výslovně používá kód ke tvorbě svých kopií a že tak činí rekurzivně1. Úspěšné vniknutí do systému je možné pouze v případě, že všechny nutné závislosti ve škodlivém kódu přesně odpovídají tomuto prostředí. Obrázek 3.1 je nedokonalou ilustrací prostředí běžného pro škodlivý kód. Dokonalé schéma podobné složitosti je v 2D prostředí obtížné vytvořit.

Diagram ukazuje, jak například samotný Office od Microsoftu představuje homogenní prostředí pro škodlivý kód a to jak na PC, tak i na počítačích Mac. Přesto však ne všechny makroviry2, které jsou schopny šíření na počítačích PC, jsou díky dalším závislostem schopny šíření na počítačích Mac. Každá vrstva totiž může tvořit další nové závislosti (kam patří i zranitelnosti) pro škodlivý kód. Je dále zajímavé sledovat, jak možný vývoj .NET na dalších operačních systémech, jako je například Linux, může zásadně změnit body závislosti a umožnit tak počítačovým virům přestup mezi jednotlivými operačními systémy. Představme si, že každý prstenec na obrázku 3.1 má v sobě drobné otvory možných penetračních bodů. Pokud všechny dírky, ve všech prstencích, umožňují svým rozmístěním prostup kódu viru, a pokud jsou všechny závislosti vyřešeny, pak je virus schopen infikovat systém.

Obrázek 3.1 naznačuje, jak složitým se výzkum počítačových virů během mnoha let stal. Boj proti počítačovým virům se s narůstajícím počtem platforem pochopitelně stále více komplikuje.

Obrázek 3.1

Běžná prostředí škodlivého kódu.

Počítačové viry – analýza útoku a obrana

63

Je důležité si uvědomit, že exploitace zranitelností systémů není nutnou podmínkou. Exploitovatelná zranitelnost je pouze jednou z mnoha závislostí.

Automatická analýza škodlivého kódu se postupně stává složitější díky rozmanitosti závislostí na prostředí. Není výjimkou strávit s virem v laboratorním prostředí mnoho a mnoho hodin ve snaze docílit alespoň běžného šíření a to zcela bez úspěchu, ačkoliv z celého světa máme zprávy o šíření z desítek, stovek a možná i tisíců zdrojů.

Další sortu virů představují případy, které jsou tak neúspěšné, že se výzkumníkům nikdy nepodaří je donutit, aby se šířily. Steve White z IBM Research například uváděl fakt, že by mohl věnovat kopii viru Whale ("matka všech virů") každému z obecenstva a přesto by nebylo potřeba se obávat šíření3. Později se však ukázalo, že virus Whale měl pouze zajímavou závislost na raných verzích architektury 80884, na které funguje bez problémů. Ještě zajímavější situace pak nastává na počítačích řady Pentium a vyšších5, kde tato závislost zcela mizí. Proto virus Whale, "dinosaurus směřující ke svému konci"6, je schopen návratu ve stylu Jurského parku.

Největší výzvou ze všech je pro počítačové výzkumníky přesné rozpoznávání typů, formátů, sekvencí kódu a vyhledání odpovídajících prostředí. Výzkumník je totiž schopen kód analyzovat pouze v závislosti na pravidlech prostředí a pomocí důkazů o jeho škodlivosti v tomto prostředí.

Za dobu své existence se viry objevily snad na všech platformách, včetně Apple II, C64, Atari ST, Amiga, PC a Macintosh, stejně jako na sálových počítačích, kapesních systémech (jakým je například PalmPilot)7, či telefonech se systémem Symbian a Pocket PC. Největší množství virů je však samozřejmě na platformě IBM PC a jejích klonech.

V této kapitole se budeme zabývat důležitou závislostí na faktorech, které ovlivňují schopnost replikace počítačových virů. Zároveň předvedeme, jak se viry mohou nečekaně vyvíjet, a také degradovat v závislosti na interakcích mezi kódem viru a prostředím, ve kterém se pohybuje.

3.1 Závislost na počítačové architektuře Většina počítačových virů se šíří ve spustitelné binární formě (ve kompilované formě). Například boot viry se šíří jako jeden nebo více sektorů kódu, využívající bootovací sekvence. Jedním z prvních zdokumentovaných případů byl Elk Cloner na prostředí Apple II, který byl také boot virem. Elk Cloner modifikoval již načtený operační systém pomocí zavěšení se na rutinu zápisu, přičemž nahráváním vlastního kódu do boot sektorů všech nově vložené disket se byl schopen šířit dál. Brain, nejstarší virus pro počítače PC, pocházející z roku 1986, je také boot virem. Přestože boot sekvence obou zmiňovaných systémů, podobně jako viry samotné, vykazovaly mnoho podobností, viry byly zcela závislé na drobných detailech svých architektur (kterou je v první řadě závislost na CPU, která bude probírána později v kapitole) a také na přesném rozložení paměti či na postupu procedury zavádění atd. Proto binární viry, obvykle bez výjimek, závisí na počítačové architektuře. To také vysvětluje, proč virus pro Apple II není schopen napadat systémy IBM PC a naopak.

Teoreticky by bylo možné vytvořit binární virus schopný fungování na více architekturách, jednalo by se však o značně náročnou úlohu. Je totiž obzvlášť složité najít způsob, jak kód vytvořený na jedné architektuře, spouštět na jiné. Mnohem jednodušší se naopak jeví možnost vložit do jednoho viru dva kódy pro dvě různé architektury. Poté je ještě potřeba zajistit, aby na konkrétní architektuře byl spouštěn

64

Kapitola 3 – Prostředí škodlivého kódu

korektní kód viru. V březnu roku 2001 virus PeElf potvrdil předpoklad, že je možné tímto způsobem vytvořit fungující, dvouplatformový, binární virus.

Autoři virů se s problémem více architektur a problémy spojenými s jednotlivými operačními systémy vyrovnali překladem kódu viru do pseudoformátu v okamžiku potřeby konkrétní architektury. Virus Simile.D (známý také jako Etap.D) od autora jménem Mental Driller používá tuto strategii na systémech Windows a Linux běžících na 32bitové architektuře Intel (a kompatibilních).

Dále je zajímavé sledovat, při jakých konfiguracích prostředí je virová infekce zastavena. Takový pokus byl zřejmě poprvé spatřen u viru Cascade, naprogramovaném německým programátorem v roce 1987, kdy virus kontroloval BIOS a v případě, že nalezl copyright firmy IBM, upustil od infekce. Tato část viru však obsahovala chybu, a virus tak ve skutečnosti infikoval všechny systémy. Autor viru ve snaze o opravu této chyby opakovaně publikoval nové verze viru, nicméně novější varianty rovněž obsahovaly chyby v této části kódu8.

Dalším druhem počítačových virů jsou ty, které jsou závislé na upgradování BIOSu. U takových typů BIOSů existuje možnost infekce. Jsou zdokumentovány pokusy o prozkoumání toto způsobu infekce ze strany známé skupiny autorů virů jménem VLAD z Austrálie.

3.2 Závislost na procesoru Závislost na procesoru postihuje především binární viry. Zdrojový kód je kompilován do objektového kódu, který je spojen do binární formy jako je například EXE (spustitelný soubor). Samotný spustitelný soubor pak obsahuje "geny" programu, jako třeba sekvenci instrukcí. Instrukce se skládají z opkódů.

Například instrukce NOP (no operation, žádná operace) nemá stejný opkód ani na jednom z trojice systémů Intel x86 – VAX – Macintosh. Na procesorech firmy Intel je opkód definován jako 0x90. Na VAX je použit opkód 0x01.

Na základě rozdílnosti tabulek opkódů a operací aktuálního procesoru by se proto sekvence bytů, po přenosu na jiný procesor, přeložila do nesmyslných spletenců kódu. Pochopitelně existuje řada opkódů, které mají smysluplný protějšek na obou systémech a některé viry toho mohou využívat. Většina počítačových virů však při kompilacích do binární podoby zachovává svou závislost na procesoru a jejich přenositelnost na jinou architekturu procesorů je nemožná.

Další forma závislosti na procesoru je ta, která nastává v okamžiku, kdy konkrétní procesor není na 100% zpětně kompatibilní s předchozími generacemi a nepodporuje správně některé vlastnosti, popř. je nepodporuje vůbec. Například virus Finnpoly nezvládá fungovat na procesorech řady 386, protože tyto procesory nekorektně provádějí instrukci CALL SP (volání související s ukazatelem na zásobník).

Protože virus předává kontrolu svému zakódovanému kódu v zásobníku pomocí této instrukce, počítač zatuhne, pokud je infikovaný soubor spuštěn na počítači vybaveným procesorem 386. Návdavkem existuje obdobný problém, objevující se u počítačů s procesory Pentium9. Dalším případem jsou klony procesoru 486 od Cyrixu, které mají chybu v "single-stepping " kódu10. Ten je používán tunelujícími viry (viz kapitola 6), jako třeba Yankee_Doodle, které pak na takových procesorech nefungují korektně.

Počítačové viry – analýza útoku a obrana

65

Poznámka Není příliš obvyklé najít počítačový virus, který nefunguje kvůli chybě v procesoru.

Některé viry se pokoušejí o spouštění příkazů, které již nejsou novějšími verzemi procesorů podporovány. Procesory 8086 Intel podporovaly instrukci POP CS, aniž by to bylo společností Intel jakkoliv dokumentováno. Později byl opkód této instrukce zneužit pro odchytávání vícebajtových tabulek opkódu.

Podobným příkladem této závislosti může být instrukce MOV CS, AX, používaná staršími počítačovými viry, jako je například italský boot-virus Ping Pong: Opkód

Assembler

Instrukce

8EC8

MOV

CS,AX

0E

PUSH

CS

1F

POP

DS

Jiné viry mohou používat koprocesor, nebo instrukce MMX (multimediální rozšíření), popř. jiné rozšíření, které v případě, že je spuštěno na stroji, který danou instrukci nepodporuje, vede k nefunkčnosti takového počítačového viru.

Některé viry používají analytické obranné techniky založené na pozměnění prefetch fronty procesoru.

Velikost prefetch fronty procesoru je u různých procesorů odlišná. Viry se pokoušejí přepsat kód v dalším instrukčním slotu, přičemž doufají, že takový kód leží mimo prefetch frontu procesoru. To také nastává při debuggingu kódu viru, takže začátečníci pokoušející se analyzovat podobné viry jsou často neúspěšní. Tato technika je efektivní proti prvním heuristickým skenerům založeným na emulaci kódu.

Nevýhodou takového virového kódu je skutečnost, že se může stát snadno nekompatibilním s různými druhy procesorů nebo dokonce s různými operačními systémy.

3.3 Závislost na operačním systému Původně bývaly operační systémy natvrdo naprogramovány pro konkrétní architekturu procesoru.

První operační systémy firmy Microsoft, jako například MS-DOS, podporovaly pouze procesory Intel.

Dokonce i Microsoft Windows podporovaly pouze hardware, který byl kompatibilní s hardware od Intelu. Přesto však v devadesátých letech vzrůstala potřeba podpory více architektur jedním operačním systémem. Windows NT byl první operační systém, který podporoval více architektur procesorů.

Většina počítačových virů je schopna fungovat pouze na jednom konkrétním operačním systému.

Dodnes však existují kompatibilní vlastnosti vedoucí napříč systémy DOS, Windows, Windows 95/98 a Windows NT/2000/XP na platformě Intel. Proto některé viry napsané původně pro DOS jsou schopny fungovat i na novějších systémech. Trendem v programování je ovšem používat méně a méně starého, "autentického" software a tím redukovat možnost podobných infekcí. Navíc některé starší triky virů už v novějším prostředí nefungují. V prostředí Windows NT už například nemohou příkazy portů z DOSových programů přistupovat přímo k hardwaru. Výsledkem je situace, kdy DOSové viry používající přímé příkazy portů zhavarují, protože operační systém vygeneruje chybu. Takto je dokonce možné

66

Kapitola 3 – Prostředí škodlivého kódu

zabránit i šíření viru, pokud jsou příkazy portů (vstupní/výstupní operace) prováděny před vlastním aktem šíření.

A dále. 32bitové viry pro Windows, které infikují pouze soubory "portable executables" (PE) se nemohou šířit pod systémem DOS, protože PE není v DOSu implementováno, a proto není možné takové soubory vykonávat. Existují ovšem ještě multipartitní viry, které jsou schopny infekce různých formátů souborů nebo systémových oblastí, což jim umožňuje přesuny z jednoho prostředí do druhého. Z toho vyplývá, že nejdůležitější závislostí na prostředí je pro binární viry samotný operační systém.

3.4 Závislost na verzi operačního systému Některé viry nejenom závisí na konkrétním operačním systému, ale pro své fungování dokonce mohou vyžadovat konkrétní verzi tohoto systému. Začínající výzkumníci často mívají problémy s analýzou takového viru. Po několika minutách neúspěšné snahy na jejich systémech se mohou mylně domnívat, že daný virus nefunguje vůbec.

Zejména v začátcích éry počítačových virů bylo možno pozorovat zástupy počítačových virů opakujících dokola stejné chyby, které je činily závislými na některé vlastnosti systému Windows. Například virus W95/Boza nepracoval na jiných, než anglických verzích systému Windows 95, takže například v českých verzích Windows nehrozilo jeho šíření.

Toto vedlo k objevu, že některé viry mohou být použity k rozšíření infekce na počítačích jednoho konkrétního národa. Například ruské systémy Windows mohou být natolik snadno rozpoznatelné od amerických, že autoři mohou úmyslně (nebo neúmyslně) cílit na tuto skupinu počítačových uživatelů.

Obecně je však jasné, že po rozšíření viru má autor viru velmi malou (nebo žádnou šanci), jak usměrňovat cesty svého výtvoru.

3.5 Závislost na souborovém systému Počítačové viry mohou být závislé na souborovém systému. Většině počítačových virů je úplně jedno, na jakém souborovém systému jsou uloženy, ať už se jedná o FAT, původně používanou systémem DOS, nebo o NTFS, používanou systémem Windows NT, nebo o vzdálený souborový systém sdílený pomocí síťového připojení. Pro tyto viry zůstává nejdůležitější především kompatibilita s nejvyšší úrovní systémového rozhraní. Viry tak bez okolků infikují soubory a vytvářejí soubory nové, aniž by dávaly pozor na aktuální formát souborového systému. Mnohé druhy počítačových virů jsou však na aktuálním souborovém systému závislé opravdu zásadním způsobem.

3.5.1 Cluster viry Je běžné, že některé viry se šíří úspěšné i na specifickém souborovém systému. Příkladem může být například bulharský virus DIR-II, který patří do kategorie tzv. clusterových virů. DIR-II využívá vlastností specifických pro některé verze DOSu a co je ještě důležitější, je schopen šíření pouze díky manipulacím v klíčových strukturách systémů založených na FAT. Na FAT v systému DOS je totiž možný přímý zápis na disk, pomocí kterého je možné přepsat ukazatel (uložený v adresářové položce) na první cluster, který obsahuje začátek uloženého souboru.

Počítačové viry – analýza útoku a obrana

67

Soubory jsou na disku uloženy jako clustery a FAT je používána DOSem k tomu, aby se tyto díly skládačky poskládaly dohromady. Virus DIR-II přepisuje ukazatel v adresářové položce takovým způsobem, aby ukazoval na konec disku, kde je uložen kód viru v nezakódované podobě. Kód je ukrytý v nepoužívané části struktury adresářových položek. Tato informace je později použita při skutečném spuštění hostitelského souboru poté, co je virus úspěšně zaveden do paměti. Pokud je virus aktivní v paměti, z pohledu uživatele vše vypadá, a také funguje jak má.

Podobné viry infikují programy extrémně rychle, stačí jim totiž změnit pouze několik bajtů v adresářových položkách. Tyto viry jsou proto označovány jako "super-rychlé" infektory1. V případě viru DIR-II je důležité si uvědomit fakt, že na každém infikovaném disku existuje vždy pouze jedna kopie viru.

V důsledku toho vypadá souborový systém v okamžiku, kdy virus není aktivní v paměti, jako "křížově propojený", protože všechny infikované soubory se odkazují na jediný cluster obsahující kód viru.

Podobnou clusterovou infekční techniku bylo možno vidět v případě viru BHP na Commodore 64, vytvořeném v roce 198611 v Německu několika autory podepsanými jako "DR. DR. STROBE & PAPA HACKER". Tento virus manipuluje s blokovými položkami hostitelských programů na disketách. Tuto techniku jsem se rozhodnul pojmenovat jako "cluster prepender". Popišme si nyní tuto prastarou techniku blíže.

Disketová mechanika počítače Commodore 1541 obvykle zvládala na každou stranu diskety uložit 166 kB dat. Dostupná kapacita každé strany diskety je rozdělena na 664 "bloků", každý má 256 bajtů. Po infekci se virus BHP pokusí pro sebe zabrat osm volných bloků. Poté přepíše "blokový" ukazatel v prvním bloku hostitelského programu tak, aby ukazoval na samotný kód viru. Kromě prvního bloku není kód hostitelského programu na disketu přesunut, namísto toho virus linkuje své bloky pomocí bloků hostitelského programu jako jediný cluster. Infikovaný program je pak spouštěn s virem v popředí. Na rozdíl od viru DIR-II může virus BHP existovat na disketě ve více kopiích. Při každé infekci je tak ztraceno osm bloků na disketě, nicméně infikované soubory ve výpisu adresáře nevypadají na první pohled podezřele a to ani v případě, kdy virus není aktivní v paměti.

Obrázek 3.2(1) ukazuje, jak vypadá program TEST infikovaný virem BHP, ve chvíli, kdy je poprvé spuštěn pomocí příkazu LOAD. Pokud si poté vypíši obsah nahraného programu pomocí příkazu LIST, objeví se příkazová řádka BASICu, zobrazená na obrázku 3.2(2). Tento systémový příkaz totiž zapříčiní spuštění binárního kódu viru. Pokud spustíme infikovaný program pomocí příkazu RUN, dostane se ke slovu virus napsaný v assembleru 6502. Při spuštění se BHP stane aktivním v paměti. Následně pak virus spustí původní program. Obrázek 3.2(2) demonstruje, jak je zpráva "HI" zobrazena poté, co je virus spuštěn. Tato zpráva je už zobrazena hostitelským programem.

Poté, co se virus BHP dostane do paměti, skryje se podobně jako virus DIR-II. Jak je patrné z obrázku 3.2(3), pokusíme se nyní program TEST spustit znovu. Když ale nyní vypíšeme obsah nahraného souboru na obrazovku, vidíme původní hostitelský program – jediný řádek s příkazem PRINT zobrazující slovo "HI". Virus je už tedy ve skrytém módu, a dokud bude aktivní v paměti, bude vždy ukazovat původní obsah souboru namísto obsahu napadeného souboru. A jako bonus má virus BHP implementovanou celou sadu sebeobranných triků. Například – virus ruší všechny pokusy o restartování počítače, aby tak zůstal déle aktivní v paměti. Dále BHP používá kontrolní součet pro prověřování vlastního binárního kódu a zjišťování možných modifikací či poškození. Paradoxně je výsledkem pouze to, že i triviálně modifikovaný virus přestane fungovat.

68

Obrázek 3.2

Kapitola 3 – Prostředí škodlivého kódu

Virus BHP na Commodore 64.

3.5.2 Viry pro NTFS Stream Souborový systém FAT je velmi jednoduchý, ale bohužel nepříliš efektivní pro všechny větší disky (v termínech FAT je totiž "velmi větší" každý disk, který má kapacitu několika gigabajtů). Různé operační systémy jako například Windows NT, vyžadují modernější souborové systémy, které by se vyznačovaly rychlostí, efektivností a hlavně možností pracovat s velkým objemem dat (pohybujícím se v jednotkách terabajtů, jak si to stále častěji žádají různé komerční databáze).

Tyto požadavky splnil až NTFS (NT File System). Málo známým faktem je to, že NTFS původně podporovalo mnohonásobně rozvětvený koncept Hierarchical File System (HPS) od firmy Apple. Windows NT musely podporovat větvení, protože serverová verze OS byla zamýšlena jako možná obsluha počítačů Macintosh. Na NTFS tak může soubor obsahovat vícenásobné streamy (multiple streams) na disku. "Hlavní stream" (main stream) je v tomto případě soubor samotný. Například kód programu notepad.exe bude obsažen v hlavním streamu. Je proto možné mít v jednom souboru několik dalších pojmenovaných streamů. Například – příkaz notepad.exe:test stream může být použit k vytvoření souboru pod jménem test. Poté, co virus WNT/Stream12 infikuje soubor, přepíše jeho hlavní stream sebou samotným, ale předtím uloží původní kód do dalšího streamu pod jménem STR. A tímto způsobem je u viru WNT/Stream patrná závislost na souborovém systému NTFS. Autoři škodlivého kódu často ponechávají své pomůcky ztracené v různých streamech na discích. Alternativní streamy totiž nejsou snadno viditelné a prakticky ani nezvětšují velikost souboru. Navíc je možné obsah alternativních streamů prohlížet bez nutnosti skladovat obsah souboru v hlavním streamu.

Tohle bude v budoucnosti určitě zneužito různými sofistikovanými červy.

3.5.3 Viry využívající kompresi NTFS Některé viry mají snahu používat kompresní techniky NTFS pro kompresi sebe a hostitelského souboru.

Tyto viry používají příkaz DeviceIoControl() API systému Windows a nastavují jim příznak FSCTL_ SET_COMPRESSION. Tato vlastnost pochopitelně vytváří závislost na NTFS a bez něj nebude virus

Počítačové viry – analýza útoku a obrana

69

pracovat. Například virus W32/HIV, vytvořený českým autorem virů jménem Benny je typickým představitelem skupiny virů závislých na NTFS. Některé viry také používají kompresi NTFS jako označení již infikovaného souboru, viz například virus WNT/Stream.

3.5.4 Infekce ISO obrazů Přestože se nejedná o běžnou infekční techniku, už jsme se setkali s útoky na nejrůznější formáty souborů, včetně formátu ISO 9660, který je definován jako standardní souborový systém. Viry mohou obraz ISO infikovat ještě před vypálením na CD. Je faktem, že mnoho virů se široce rozšířilo právě díky CD-R diskům, které už není možné po vypálení dezinfikovat. ISO obrazy v mnoha případech navíc disponují souborem AUTORUN.INF, který ve Windows zajišťuje automatické spouštění programů. Viry toho mohou využít a modifikovat tento soubor ke svému prospěchu. Tuto techniku poprvé použil ruský autor virů jménem Zombie již na začátku roku 2002.

3.6 Závislost na formátu souboru Viry mohou být zařazeny do kategorií dle souborových objektů, které napadají. Tato krátká sekce je úvodem do problematiky binárních infektorů, jimiž se detailněji budeme zabývat v kapitole 4.

3.6.1 COM viry v prostředí DOSu Viry jako Virdem a Cascade napadají pouze DOSovské binární soubory s koncovkou COM. Tyto COM soubory nemají žádnou specifickou strukturu, a proto jsou pro viry snadným cílem. Existují tucty možných variant napadení.

3.6.2 EXE viry v prostředí DOSu Další kategorii představují viry, které umí napadat pouze DOSovské EXE soubory. EXE soubory začínají malým záhlavím se strukturou, obsahující mimo jiné i vstupní body programu. Viry infikující EXE soubory často modifikují pouze bod vstupu hostitele, přičemž se připojí na konec souboru. Technik útoků na EXE soubory je řádově více, než u COM souborů.

EXE soubory začínají identifikátorem MZ, pocházejícím z monogramu inženýra Microsoftu Marka Zbikowskiho, který tento formát navrhl. Překvapením ovšem zůstává skutečnost, že některé verze DOSu akceptují jak identifikátor MZ, tak i opačnou verzi – ZM. To je také důvod, proč některé bulharské viry infikují obě varianty. Pokud skener rozpozná EXE soubor založený na signatuře MZ, může mít problém při detekci ZM varianty. Některé šikovné DOSové viry tyto dvě signatury navíc často zaměňují, aby zmátly antivirové programy, nebo to dělají pro označení již infikovaných programů.

Dezinfekce EXE souborů je obecně komplikovanější než u COM souborů. V principu jsou však obě metody podobné. Informace v hlavičce, stejně jako i zbytek souboru, musí být obnoven.

3.6.3 NE (New Executable) viry pro 16bitová Windows a OS/2 Jeden z prvních virů pro Windows byl W16/Winvir. Winvir používal DOSovských přerušení k infekci formátu souborů NE pro Windows. To bylo možné proto, že tehdejší verze Windows v pozadí používaly

Kapitola 3 – Prostředí škodlivého kódu

70

systém DOS. Tyto NE soubory mají mnohonásobně složitější strukturu než EXE soubory. NE soubory tak začínají starou DOSovou EXE hlavičkou umístěnou na začátku souboru, následovanou hlavičkou novou, která začíná identifikátorem NE. Jedna z nejzajímavějších infekčních technik souborů NE je použita u rodiny virů W16/Tentacle_II, která byla nalezena v červnu roku 1996 současně ve Spojených Státech, Velké Británii, Austrálii, Norsku a na Novém Zélandu. Nejenom, že se viry rodiny Tentacle_II úspěšně šířily, ale byly také velmi těžko odstranitelné, především díky značné složitosti NE souborů. Tento virus si dále rozebereme v kapitole 4.

3.6.4 LX viry na OS/2 Formát "Linear eXecutable" (LXs) představila společnost IBM v novějších verzích operačního systému OS/2. Objevilo se pouze několik málo virů. Například OS2/Myname je jednoduchý, přepisující virus.

Myname používá řadu systémových volání jako DosFindFirst(), DosFindNext(), DosOpen(), DosRead() a DosWrite() k vyhledávání obětí. Poté přikročí k jejich přepsání. Virus vyhledává soubory se spustitelnými koncovkami v aktuálním adresáři. Vůbec se nepokouší identifikaci OS/2 LX souborů, jednoduše přepíše všechny soubory svojí kopií. OS2/Myname je závislý na formátu LX a prostředí systému OS/2.

Verze viru OS2/Jiskefet se šíří podobným způsobem. Tento virus ale navíc vyhledává soubory obsahující hlavičku LX: cmp

word ptr [si], 'XL'

jnz

NO

Hlavička souboru je načtena virem, přičemž registr "si" (source index) je zde použit pro kontrolní označení. Pokud označení není nalezeno, virus soubor nepřepíše. Tím je závislost viru Jiskefet na formátu LX ještě patrnější, než u viru Myname.

3.6.5 Viry napadající soubory PE prostředí 32bitových Windows První virus schopný infekce PE souborů byl W95/Boza, napsaný nějakým členem australské virové skupiny Vlad pro betaverzi systému Windows 95.

Virus byl původně autorem pojmenován jako Bizatch. Jméno Boza následně získal od Vesselina Bontcheva. Boza je bizarní bulharský nápoj, který barvou i konzistencí připomíná bahno, je to nápoj, který si málokdy oblíbí jakýkoliv ne-bulhar. Bontchev toto jméno nevybral pouze pro jeho zvuk podobný původnímu jménu, ale hlavně proto, že virus považoval za "chybový a celkově zmateně napsaný". Bulharský idiom "toto je velká boza" totiž znamená "toto je zmatené a nejasné".

Autora viru, který vystupuje pod přezdívkou Quantum, tímto dozajista příliš nepotěšil, ale takový byl Bontchevův záměr. Později bylo dokonce možné se setkat s viry, které útočí na databáze antivirových programů a mění v nich jméno Boza na Bizatch, takže při detekci viru pak antivirus hlásí původní jméno viru. Tato situace skvěle ilustruje psychologickou bitvu odehrávající se mezi autory virů na jedné straně a antivirovými výzkumníky na straně druhé.

Protože infekce PE souborů v současnosti patří mezi nejběžnější způsoby infekce, budeme se jejím rozborem podrobněji zabývat v kapitole 4. Formát souborů PE je dnes běžně využíván nejrůznějšími

Počítačové viry – analýza útoku a obrana

71

binárními programy, včetně běžných systémových komponent, běžných aplikací, spořičů obrazovky, ovladačů zařízení, nativních aplikací, dynamických knihoven a ovladačů ActiveX. Nový 64bitový formát souborů PE+ už podporuje 64bitovou architekturu IA64, AMD64 a EM64T. Antiviroví výzkumníci předpokládají, že 64bitové viry pro Windows napadající nativní 64bitový kód budou brzy následovat.

Takovým virem je například W64/Rugrat.334413, který se objevil v březnu roku 2004 a který vytvořil autor pod jménem "roy g biv". Vir Rugrat je celý vytvořen v assembleru pro IA64. Virus je poměrně kompaktní – je dlouhý zhruba 800 řádků. Rugrat využívá nejmodernějších vlastností nabízených procesory řady Itanium, mezi které patří například i predikce kódu. Kromě toho, autor "roy g biv" v létě 2004 vypustil další virus – W64/Shruggle. Virus W64/Shruggle umí infikovat soubory formátu PE+, běžící na nejnovější 64bitové architektuře procesorů AMD64.

3.6.5.1 Viry napadající dynamické knihovny Virus W95/Lorez byl jeden z prvních 32bitových virů pro Windows schopný infekce souborů dynamických knihoven (DLL). Soubory DLL používají stejný systém uspořádání dat jako soubory PE. Dynamické knihovny jsou navíc schopny exportu funkcí, které jsou použitelné dalšími aplikacemi.

Rozhraní mezi aplikacemi a dynamickými knihovnami je zajištěno exportem z DLL a importem do spustitelných souborů. Virus Lorez jednoduše infikuje klientskou komponentu KERNEL32.DLL. Modifikací exportního adresáře DLL pak mohou viry snadno přistupovat k rozhraní API. Infekce souborů DLL se postupně rozšiřovala a svého vrcholu dosáhla příchodem červa Happy99 (známého také jako W32/SKA.A), vytvořeného autorem jménem Spanska na počátku roku 1999. Obrázek 3.3 ukazuje payload červa Happy99 v podobě ohňostroje.

Obrázek 3.3

Payload červa Happy99.

A podobně jako další červi s napojením na prázdniny, i tento červ využívá období před Novým rokem a maskuje se jako atraktivní novoročenka.

72

Kapitola 3 – Prostředí škodlivého kódu

Červ Happy99 injektuje několik zavěšení do knihovny WSOCK32.DLL, především pak API connect() a send(). Pomocí nich monitoruje e-maily a diskusní skupiny. Červ Happy99 také vyvolal debatu ohledně zařazení tohoto typu škodlivého kódu tím, že v sobě nesl následující zprávu určenou antivirovým výzkumníkům: Is it a virus, a worm, a trojan? MOUT-MOUT Hybrid (c) Spanska 1999.

3.6.5.2 Nativní viry V současnosti jsme svědky rozšiřující se popularity nového druhu 32bitových virů pro Windows – infektorů nativního kódu. První takový virus, W32/Chiton, byl vytvořen autorem "roy g biv" na sklonku roku 2001. Narozdíl od běžných Win32 virů, které se spoléhají na subsystém Win32 umožňující replikaci pomocí funkcí API, virus W32/Chiton je schopen infekce mimo subsystém Win32.

Soubor PE je totiž možné nahrát jako ovladač zařízení, GUI aplikaci, konzolovou aplikaci nebo jako nativní aplikaci. Nativní aplikace, kterou je například autochk.exe, se spouštějí v průběhu bootování.

Protože se spouští ještě předtím, než jsou k dispozici subsystémy, jsou zodpovědné za vlastní hospodaření s pamětí. V hlavičkách svých souborů mají hodnotu "PE.OptionalHeader.Subsystem" nastavenu na 0001 (Native).

Položka HKLM\System\CurrentControlset\Control\Session Manager\BootExecute obsahuje názvy a argumenty nativní aplikace, která je programem Session Manager spouštěna v době bootování. Program Session Manager tyto aplikace hledá v adresáři Windows\System32 pod obvyklými názvy specifickými pro nativní aplikace.

Nativní aplikace mají k dispozici NTDLL.DLL (nativní API), obsahující stovky API, které ovšem nejsou společností Microsoft stále zdokumentovány. Nativní aplikace se tedy nemohou spoléhat na subsystém knihoven DLL, jako je například KERNEL32.DLL, protože v době spouštění nativních aplikací ještě nejsou k dispozici. Počítačové viry jsou však schopny vyvolat celou řadu API z knihovny NTDLL.DLL, a je tedy zjevné, že autoři virů se toto rozhraní naučili využívat až do posledního parametru.

Virus W32/Chiton využívá následující API knihovny NTDLL.DLL pro práci s pamětí, vyhledávání souborů a správu souborů: 1. Práce s pamětí: RtlAllocateHeap() RtlFreeHeap()

2. Vyhledávání souborů a adresářů: RtlSetCurrentDirectory_U() RtlDosPathNameToNtPathName_U() NtQueryDirectoryFile()

3. Správa souborů: NtOpenFile() NtClose() NtMapViewOfSection()

Počítačové viry – analýza útoku a obrana

73

NtUnmapViewOfSection() NtSetInformationFile() NtCreateSection()

Nativní viry mají schopnost se spouštět v procesu bootování, což jim poskytuje značnou výhodu při infikování dalších aplikací. Tento druh virů je svou strukturou dosti podobný virům pracujícím v režimu jádra. Není proto překvapením, že se obáváme možného budoucího spojení těchto dvou technik.

3.6.6 Viry infikující soubory ELF v prostředí systému UNIX Bohužel ani v prostředí operačního systému UNIX a jemu příbuzných systémů nejsme ušetřeni virové hrozby a právě na této platformě jsou ve většině případů použity soubory ve formátu ELF14. Pro soubory ELF je typické, že nemají žádnou koncovku a identifikovány jsou na základě interní struktury.

Podobně jako soubory PE, mohou i soubory ELF podporovat více než jednu platformu procesoru. Navíc soubory ELF podporují jak 32bitové, tak i 64bitové procesory bez dodatečných úprav, narozdíl od souborů PE, které k tomu potřebují drobné updaty, které zajistí potřebnou kompatibilitu v 64bitovém prostředí (výsledkem je již zmiňovaný formát PE+).

Soubory ELF obsahují krátkou hlavičku, soubor je rozdělen do logických sekcí. Většina virů šířící se na systému Linux napadá právě tento formát. Je však jisté, že většina virů pro Linux je poměrně jednoduchá15. Například virus Linux/Jac.8759 je schopen infikovat soubory pouze v aktuálním adresáři.

Jedním z nejkomplexnějších virů pro Linux, {W32,Linux}/Simile.D (známý i jako Etap.D), jako první použil techniku využívající vstupní bod (více v kapitole 4). Úspěch viru Simile.D je samozřejmě závislý na stupni zabezpečení konkrétního systému souborů. Soubory s právem zápisu budou automaticky infikovány, o další zvyšování práv přístupu se virus nepokouší.

Zdá se, že útoky počítačových moderních červů (jako v případě červa Linux/Slapper) budou variacemi na infekce souborů ELF na systémech Linux. Zvýšení práv je často možné dosáhnout exploitací síťových služeb a využívat tak snadnějšího přístupu k binárním souborům.

Hlavním problémem virů infikujících ELF soubory je chybějící binární kompatibilita mezi různými distribucemi systémů UNIX. Rozmanitost binárního kódu na různých procesorech pochopitelně přináší závislost na knihovnách. Proto viry napadající soubory formátu ELF často trpí vážnými problémy a namísto infekce způsobí pád jádra.

3.6.7 Viry napadající ovladače zařízení V době DOSu jsme se s nimi setkávali minimálně, ačkoliv tomuto způsobu infekce bylo věnováno několik článků různých magazínů pro tvůrce virů, jako například 40Hex. Ovladače zařízení pro oblíbené operační systémy mají ve zvyku mít vlastní binární formát, ale protože se jedná o speciální formy obecněji spustitelných formátů pro tyto platformy, je možné je infikovat běžnými infekčními strategiemi.

Například 16bitový řadič systému Windows musí být ve formátu LE (linear executable). Formát LE je velmi podobný formátu souborů LX známému z prostředí OS/2. Je tedy jasné, že tyto soubory jsou těmito viry napadány také.

74

Kapitola 3 – Prostředí škodlivého kódu

V prostředí Windows 9x existuje formát VxD (virtuální ovladač zařízení), který však nebyl nikdy firmou Microsoft oficiálně zdokumentován pro použití širší programátorskou obcí. Výsledkem je, že virů schopných infekce souborů VxD je jako šafránu. Například vir W95/WG infikuje soubory VxD a modifikací vstupního bodu je schopen spustit externí soubor pokaždé, když je infikovaný VxD soubor nahrán do paměti. Takto je v souboru VxD modifikována pouze hodnota vstupního bodu, což umožňuje nahrát kód viru z externího zdroje.

Jiné viry, například rodina W95/Opera, infikuje soubory VxD tak, že kód viru připojí na konec souboru a úpravou vstupního bodu souboru VxD se z něj sám spustí.

V současnosti je možné sledovat rozmach infekcí ovladačů systému Windows XP. U systémů založených na technologii NT jsou ovladače zařízení klasické PE soubory, které jsou napojeny na funkce jádra NT. V současnosti několik virů využívá zavěšení ovladače přerušení INT 2E (služby systému NT založeného na IA32) v režimu jádra, čímž jsou schopni infikovat soubory za běhu. Například rodiny virů WNT/Infis a W2K/Infis jsou schopny infekce přímo v režimu jádra u systémů Windows NT a Windows 2000. Český autor virů Ratter zveřejnil v roce 2003 virus W32/Kick. W32/Kick infikuje pouze soubory ovladačů zařízení SYS ve formátu PE. Virus se nahraje do paměti v režimu jádra, ale jeho infekční rutina běží v uživatelském módu a soubory infikuje přes standardní Win32 API.

Poznámka Více podrobností o strategiích počítačových červů ohledně paměti je k dispozici v kapitole 5.

3.6.8 Viry infikující objekty a LIB Infekce napadající objekty a LIB nejsou běžné. Protože je zde příliš patrná závislost na vývojovém prostředí, existuje v současnosti pouze tucet takových virů.

Zdrojový kód je nejprve zkompilován do podoby objektového kódu, a poté linkován do podoby spustitelného souboru: Zdrojový kód - Objektový kód / Kód knihovny - Spustitelný soubor.

Viry útočící na objekty nebo na knihovny využívají parsování. Například virus Shifter16 umí infikovat soubory objektů. Podobné viry se pak šíří v několika fázích, jak můžete vidět na obrázku 3.4.

Fáze 1. Infikovaný soubor je spuštěn na hostitelském systému.

Fáze 2. Kód viru vyhledává a infikuje další soubory.

Fáze 3. Soubory objektů a knihoven jsou linkovány uživatelem jako součást nového projektu.

(A fáze jedna se může opakovat.)

Obrázek 3.4

Fáze infekce viru Shifter.

Počítačové viry – analýza útoku a obrana

75

Shifter pochází od autora jménem Stormbringer, který jej vytvořil v roce 1993. Virus opatrně kontroluje, zdali je soubor objektu připraven k linkování do spustitelného tvaru. Tento způsob využívá kontrolu offsetu položky vstupního záznamu souboru objektu. Pokud je jeho hodnota rovna 0x100, virus se objekt pokusí infikovat v okamžiku, kdy je linkován, čímž se tak dostane na začátek spustitelného souboru COM.

3.7 Závislost na překladači Různé třídy virů mají závislost na překladačích daných prostředí. Takřka každá větší aplikace svým uživatelům poskytuje možnost programovatelnosti. Například produkty Office od Microsoftu poskytují uživatelům bohaté programovatelné prostředí maker, podporující Visual Basic pro aplikace. (Starší verze programu Word, zvláště pak Word 6.0/Word 95 podporují pouze WordBasic.) Tato interpretovaná prostředí často znamenají pro viry možnost značného vylepšení svých schopností a možnost rozšíření se na další platformy.

3.7.1 Makro viry v produktech firmy Microsoft V současnosti existují tisíce makro virů, mnohé z nich jsou doposud v oběhu. Uživatelé si mezi sebou často vyměňují soubory vytvořené v prostředí produktů Office firmy Microsoft jako například Word, Excel, PowerPoint, Visio nebo dokonce Access a Project. S prvním, velmi široce rozšířeným, makro virem jsme měli tu čest v případě WM/Concept.A na konci roku 199517. Během pár měsíců jsme nalezli pouze tucet podobných virů, ale do roku 1997 už existovaly tisíce podobných výtvorů. Makro virus XM/Laroux18, objevený v roce 1996, byl velmi rozšířeným makro virem, který infikoval jednotlivé sešity programu Excel. Prvním známým makro virem pro Word byl WM/DMV, vytvořený roku 1994. Autor viru WM/DMV také vytvořil funkční makro virus napadající i makra Excelu (XM).

Obrázek 3.5 ilustruje pohled na OLE2 soubor používaný produkty firmy Microsoft. Microsoft tuto strukturu dosud veřejně nepublikoval.

Povšimněte si především, že produkty firmy Microsoft nepracují přímo se soubory OLE2. Důsledkem toho je fakt, že makro viry v podobném prostředí Microsoftu neinfikují přímo OLE2 soubor, protože k tomuto přistupují produkty Microsoftu přes OLE2 API. Dále si povšimněte různých verzí podobných programů firmy Microsoft používajících různé jazyky.

Na začátku OLE2 souborů můžeme najít identifikátor, tvořený sekvencí bajtů "D0 CF 11 E0," což na první pohled připomíná slovo DOCFILE (s malým L). Tyto hodnoty mohou ve formátech big-endian a little-endian lišit. Různé betaverze produktů Microsoftu mohou podporovat i další hodnoty. Záhlaví informačního bloku obsahuje ukazatele na různé datové struktury obsažené uvnitř souboru. Mezi jinými důležitými hodnotami tak například obsahuje ukazatele FAT a Directory. OLE2 soubory jsou navíc podobné úložištím založených na FAT systému MS-DOS. Největším problémem souborů OLE2 je jejich extrémně komplexní struktura. Jsou vlastně souborovými systémy v souboru. Obsahují vlastní clustery, alokační tabulky, kořenový adresář, podadresáře (zde nazývanými jako úložiště, "storages"), soubory (nazývanými "streams") atd.

Základní velikost sektoru je 512 bajtů, jsou ale dovoleny i větší hodnoty. (V některých implementacích umožňuje mini-FAT19 menší velikosti "sektorů".) Produkty Office lokalizují makra vyhledáváním Di-

76

Kapitola 3 – Prostředí škodlivého kódu

rectory OLE2 souborů pro úložiště VBA. Makra pak vypadají jako streamy uvnitř dokumentu. Stejně jako v normálních souborových systémech se i tady data fragmentují, a rovněž se zde mohou vyskytnout nejrůznější chyby. Naneštěstí je také možné, že budou poškozena i makra samotná a jak dále sami uvidíte, tohle přispívá k přirozené tvorbě nových verzí makro virů.

Dokumenty navíc obsahují uvnitř speciální bit, nazývaný jako dočasný bit (template bit). Pokud je tento dočasný bit vypnutý20, WinWord 6/7 makra vůbec nevyhledává.

Obrázek 3.5

Pohled na strukturu OLE2 souboru.

Makro viry jsou tedy uloženy uvnitř dokumentu, namísto obvyklého začátku nebo konce souboru. Ještě horší je skutečnost, že makra jsou doslova "pohřbena" uvnitř samotných streamů, které mají samy o sobě dost komplexní strukturu. Při prohledávání struktury OLE2 bez znalosti o jejím rozložení, je možné snadno přehlédnout fakt, že se makro virus rozdělí na bloky až po 64 bajtech.

Hlavní výzvou při odstraňování škodlivého kódu z maker je záchrana původních uživatelských maker v dokumentu. V mnoha případech je ale prostě nemožné odstranit virus bez zničení uživatelských maker. Uživatelé by samozřejmě rádi získali svá makra zpět, bohužel to však není vždy možné.

Makro viry se tvoří snadněji nežli jakýkoliv jiný druh souborových infektorů. Navíc je samotný kód viru přístupný komukoliv v dosahu infekce. Přestože to silně zjednodušuje analýzu, poskytuje to výhodu především útočníkovi, protože zdrojový kód viru je snadno přístupný a může být jednoduše modifikován.

Pro lepší pochopení vnitřní struktury dokumentů OLE2 se podívejme na fragment komentáře viru W97M/Killboot.A zobrazeného pomocí aplikace DocFile Viewer firmy Microsoft. Viz obrázek 3.6. Program DocFile Viewer je součástí balíku Visual C++ 6.0 od Microsoftu. Tento nástroj může být použit pro prohledání úložiště dokumentů a nalezení streamu "ThisDocument" v adresáři Macros\VBA.

Počítačové viry – analýza útoku a obrana

Obrázek 3.6

77

Virus W97M/Killboot.A v DocFile Vieweru.

Stream "ThisDocument" můžeme tímto způsobem zkoumat dále a nalézt samotný kód viru. Na obrázku 3.6 můžeme vidět komentář od samotného autora viru: E0 00 00 00 39 00 73 65 74 20 74 68 65 20 64 61 ....9.set the da 79 20 6F 66 20 41 72 6D 61 67 65 64 64 6F 6E 2C y of Armageddon, 20 74 68 65 20 32 39 74 68 20 64 61 79 20 6F 66

the 29th day of

20 74 68 65 20 6E 65 78 74 20 6D 6F 6E 74 68 00

the next month.

Opkód 0xE0 je použit pro komentář, 0x39 reprezentuje velikost komentáře. Předchozí řádky jsou přeloženy takto: 'set the day of Armageddon, the 29th day of the next month

Opkód samotný je závislý na verzi VBA, a proto může být bajt 0xE0 změněn na jinou hodnotu, v závislosti na potížích21 programu Word s konverzí (up-conversion, down-conversion).

Jedním z nejzajímavějších aspektů makro virů je to, že přinášejí zcela novou oblast problémů, kterou doposud nebylo možné spatřit u žádného typu počítačových virů.

3.7.1.1 Poškození maker Mnohé makro viry se do nových souborů kopírují pomocí kopírovacích příkazů maker. Makro virus se tak do dokumentu může zkopírovat buď tímto způsobem, nebo může prvně zaútočit na globální nastavení v souboru NORMAL.DOT, přičemž se pak z tohoto globálního nastavení rozkopíruje zpátky do uživatelských dokumentů.

Přirozená mutace není v prostředí programu Microsoft Word výjimečná22. Skutečné důvody pro toto poškození nebyly dosud nalezeny, ale předpokládá se, že poškození je spojeno s problematickým uklá-

Kapitola 3 – Prostředí škodlivého kódu

78

dáním dokumentů na diskety. Někteří uživatelé totiž často nepočkají, až je dokument dokonale uložen na disk, což může vyústit v několika-bajtové poškození v těle makra. Protože Word intepretuje kód VBA řádek po řádku, nevygeneruje žádnou chybovou zprávu, pokud není kód vysloveně chybný1.

Už víme, že makra jsou v dokumentech Wordu uložena jako binární data. Pokud je takový kód poškozen, virus často přežije a dále funguje alespoň částečně. Problém je, že podobných poškození existuje velké množství a jsou tak běžné, že pro každou rodinu makro viru je možné najít až stovky odlišných variant. Například rodina WM/Npad má mnoho variant, které jsou spíše důsledkem přirozeného poškození, než důsledkem úmyslného vytvoření.

Poškozené makro viry mohou být tedy i nadále funkční. Zde uvádíme některé důvody tohoto často pozorovaného chování: 

VBA kód potřebný pro zkopírování makra do jiného dokumentu je příliš krátký.



I pouhé jedno fungující makro může vytvořit tucty poškozených maker.



Vedlejší efekty poškození se objevují pouze ve výjimečných případech.



Poškození nastalo až po zkopírování virového kódu.



Virus podporuje handler "On Error Resume Next".

Zvažte příklad uvedený ve výpisu 3.1.

Výpis 3.1 Příklad poškozeného makra.

Sub MAIN SourceMakro$= FileName$()+ "Foobar" DestinationMakro$ = "Global:Foobar" MakroCopy(SourceMakro$, DestinationMakro$) // Poškození zde// End Sub

Protože většina makro virů vkládá error handler na začátek svého kódu, kompilace makro viru a jeho spouštění má tendenci být odolné proti většině závažných poškození.

Protože mnoho antivirových produktů používá k vyhledávání a identifikaci makro virů kontrolní součty, je možné, že v případě takových poškozených variant nebudou tyto antiviry fungovat správně. Použití kontrolních součtů je však jedinou cestou, jak exaktně identifikovat každou odlišnou variantu.

Jiné druhy virů, jako třeba viry napsané v assembleru, většinou přestanou v případě nějakého poškození ihned fungovat. Naopak makro viry často z nejrůznějších důvodů přežijí.

3.7.1.2 Konverze makra Při vytváření programu Word 97 a následné podpoře VBA se Microsoft rozhodl vytvořit nový formát dokumentu a začal používat ještě "výkonnější" makro-jazyk. Pro řešení možných problémů s kompatibilitou se vývojáři rozhodli automaticky převádět stará makra do nového formátu. Důsledkem může být

Počítačové viry – analýza útoku a obrana

79

situace, kdy v případě viru pro Word 95 ve formátu WordBasic, který je otevřen v novější verzi Wordu, dojde k vytvoření úplně nového viru, nebo převedení starého viru do nového prostředí. Takto jsou například WM viry převedeny do formátu W97M atd.

Tento problém konverze maker představuje zdroj mnoha problémů pro výzkumníky. Někteří se domnívali, že takový převod je neetický, zatímco další už chápali, že je to jediná cesta, jak chránit zákazníky.

Dnes už jsou dostupné techniky23 umožňující převod různých formátů maker do kanonické formy, a tak může být detekce provedena kanonickým způsobem, na základě jediné definice. Toto detekci makro virů značně zjednodušuje a redukuje velikost databáze antivirového skeneru, protože k detekci viru je potřebné menší množství dat, nehledě na mizící potřebu replikovat viry pro různé platformy produktů Office.

3.7.1.3 Závislost na jazyku lokalizace Při použití základních makro příkazů přeložených Microsoftem, jako je například FileOpen v lokalizovaných verzích produktů Office, je patrné zúžení možností těchto virů na jednotlivé lokalizované verze produktů, jakou je například německá verze. Tabulka 3.1 na následující stránce uvádí nejběžnější jména maker v různých lokalizovaných verzích programu Microsoft Word.

Tabulka 3.1 – Nejběžnější jména maker v lokalizovaných verzích programu Microsoft Word Anglicky

Finsky

Německy

FileNew

TiedostoUusi

DateiNeu

FileOpen

TiedostoAvaa

DateiOffnen

FileClose

TiedostoSulje

DateiSchliesen

FileSave

TiedostoTallenna

DateiSpeichern

FileSaveAs

TiedostoTallennaNimmella

DateiSpeichernUnter

FileTemplates

TiedostoMallit

DateiDokVorlagen

ToolsMakro

TyoAkalutMakro

ExtrasMakro

Španělsky

Francouzsky

Italsky

ArchivoNuevo

FichierNouveau

FileNuovo

ArchivoAbrir

FichierOuvrir

FileApri

ArchivoCerrar

FichierFermer

FileChiudi

ArchivoGuardar

FichierEnregister

FileSalva

ArchivoGuardarComo

FichierEnregisterSous

FileSalvaConNome

ArchivoPlantillas

FichierModules

FileModelli

HerramMakro

OutilsMakro

StrumMakro

Kapitola 3 – Prostředí škodlivého kódu

80

Různé produkty Office navíc používají odlišné názvy maker. Několik příkladů vyskytujících se u anglické verze Microsoft Office uvádí tabulka 3.2.

Tabulka 3.2 – Rozdíly ve jménech maker mezi programy Word a Excel.

Microsoft Word

Microsoft Excel

AutoClose

Auto_Close

AutoOpen

Auto_Open

Virus WM/CAP.A24 je typickým příkladem závislosti na jazyce, protože používá indexování menu. Indexování menu bylo týmem Microsoft Accessu vývojářům maker silně doporučováno. Důsledkem je ale fakt, že indexovaná menu fungují spolehlivě pouze v případech, kdy hostitelské prostředí nebylo nijak přizpůsobováno.

Virus WM/CAP.A uživatele klame tím, že je nechává si myslet, že své soubory ukládají ve formátu RTF (Rich Text Format), ačkoliv se ve skutečnosti infikované soubory ukládají ve formátu DOC. Uživatelé totiž často dávají formátu RTF přednost, aby zabránili aktivním makrům v ukládání se do jejich dokumentů. Virus se brání tím, že přebírá kontrolu nad funkcí File/SaveAs... a ukládání v jiném formátu nepovoluje25.

3.7.1.4 Závislost makro virů na platformě Přestože většina makro virů není závislá na platformě, několik případů této závislosti se přece jenom našlo. Produkty Microsoft Office existují nejenom pro Windows, ale jsou dostupné i pro systémy Macintosh. Ne všechny makro viry jsou ovšem schopny fungování na obou platformách, a to především díky následujícím důvodům.

Volání funkcí Win32 Několik makro virů pro své vlastní potřeby definuje vlastní volání funkcí API z Win32 řady systému Windows. Takové viry na systémech Macintosh nefungují, neboť příslušná API na nich nejsou implementována. Příkladem může být například virus WM/Hot.A z ledna 1996, používající volání API funkce GetWindowsDirectory()26.

Declare Function GetWindowsDirectory Lib "KERNEL.EXE" \ (Buffer As String, Size As Integer) As Integer : : GetWindowsDirectory(WinPath$, SizeBuf)

Některé šikovné makro viry používají zpětné volání funkcí Win32 ke spouštění svého kódu i mimo koncept vlastního interpretu maker. Například jednoduchá proměnná string může být definována takovým způsobem, aby obsahovala celý kód napsaný v assembleru. Časté je použití funkce chr() pro vytvoření delších řetězců obsahujících kód. Poté je rutina zpětného volání použita pro běh řetězce jako kódu. Tím-

Počítačové viry – analýza útoku a obrana

81

to způsobem makro virus vystoupí z kontextu interpretu makro jazyka a stává se závislým na procesoru a platformě, na které je spuštěn.

Například virus {W32, W97M}/Heathen.12888 používá API funkce CallBack12(), CallBack24() a CreateThread() souboru KERNEL32.DLL pro infekci a rozšiřování se jak v dokumentech, tak i ve spustitelných souborech.

Umístění souborů v úložištích Další klíčová odlišnost mezi operačními systémy je umístění souborů na disku. Některé makro viry mají některé cesty naprogramované natvrdo, a tak například fixně zadaná cesta k šabloně NORMAL.DOT na disku C: samozřejmě není funkční na systémech Macintosh.

Viry navíc v mnoha případech očekávají souborový systém ve stylu Windows, a to dokonce i v případech, když používají "korektní" metody VBA pro získání adresářové struktury.

Modifikace registrů Některé makro viry pro použití nových triků nebo pro ukládání proměnných modifikují hodnoty položek registru na systémech Windows. Podobné chování představuje další závislost – v tomto případě na použitém operačním systému.

3.7.1.5 Vývoj a degenerace makra Makro viry se vyskytují buď ve formě jediného makra, nebo ve formě celé sady maker. Protože antivirem musí být rozpoznány všechny makro soubory, v případě přístupu jednoho makra k jinému makru vzniká celá řada problémů.

Některé makro viry totiž mohou používat jinou sadu maker, než tu, ve které jsou vytvořeny. Některé makro viry kradou makra z dokumentů, které předtím infikovaly a mohou se tímto způsobem vyvíjet do nových forem. A naopak – některé viry mohou své části ztrácet, čímž dochází k jisté degradaci jejich funkcí v nových formách27. Známy jsou též případy tzv. "sendvičů"28, které pozorujeme tehdy, když jeden virus (ať už makro virus nebo skriptovací virus) sdílí s jiným virem název nebo soubor skriptu.

Při detekci a dezinfekci tak vzniká řada zajímavých situací, popsaných Richardem Fordem29. Problém může nastat například tehdy, když antivirový produkt detekuje podtyp známého makra ("zbytky makro viru") ze sady maker novější verze viru s alespoň jedním novým makrem mezi již dříve známými makry. Pokud nyní antivirový program odstraní známá makra, může tak nevědomky vytvořit novou verzi viru, zejména v případě, kdy ponechaná makra jsou dále schopna své funkce. Tomuto problému je možné zabránit několika způsoby, z nichž nejrazantnější variantou je ta, která vyžaduje odstranění všech maker z infikovaných dokumentů (což také znamená odstranění maker vytvořených uživatelem).

Výzkumníci doporučují definovat minimální sadu maker nutnou pro "bezpečné odstranění" virových maker z dokumentu (u známého viru). Bohužel je ještě potřeba započítat rozšíření problému Richarda Forda nalezené Igorem Muttikem, které bylo detailněji popsáno ve vědecké práci Vesselina Bontcheva30.

Toto rozšíření je známo jako "Igorův problém".

V něm předpokládáme existenci viru známého jako Foobar, skládajícího se z jediného makra nazvaného jako M. Antivirový program identifikuje M jako napadený dokument, ale při odstraňování infekce

82

Kapitola 3 – Prostředí škodlivého kódu

narazíme na problém. Ten nastal z toho důvodu, že varianta viru Foobar je aktivní v paměti. Tato varianta se skládá ze dvou maker {M, P}. Bohužel – antivirový program nezná druhé makro P, a proto ponechá při dezinfekci makro P nepovšimnuté. Hlavní problém pak nastává v případě, kdy P je samo o sobě plně funkčním virem. Potom je antivirový program, i přes přesnou identifikaci viru Foobar, tvůrcem nové verze viru. Proto je ponechávání částí maker při odstraňování viru nebezpečné.

Prostředí škodlivých programů a antivirů tedy může být původcem změn v počítačových virech a vést jak k vývoji, tak i degradaci schopností jednotlivých virů. V jednom dokumentu se navíc často setkáváme s mnohonásobnými infekcemi od různých makro virů, což vede ke "křížení" hrozeb a nepředvídatelnému chování. Náhodně také dochází i k jisté "sexualitě" – viry si mohou navzájem vyměňovat jednotlivá makra, "geny", a následně se vyvíjet nebo degradovat.

3.7.1.6 Život si vždy najde cestu – zdroj, p-kód a spustitelný kód Souborové formáty společnosti Microsoft musely být antivirovými firmami pomocí reverzního inženýrství opětovně vytvořeny, aby byly jejich produkty schopny detekovat viry v prostředí těchto souborových formátů. Přestože Microsoft nabídnul antivirovým výzkumníkům specifikace podle NDA, tyto informace často obsahovaly zásadní chyby nebo byly rovnou nekompletní31.

Některé antivirové firmy jsou známy tím, že byly v tomto případě reverzního inženýrství úspěšnější než druhé. Důsledkem této situace je v antivirových firmách možné najít nový druh experta – je jím expert na souborové formáty. Mezi nejlepší experty v tomto oboru patří Vesselin Bontchev, Darren Chi, Peter Ferrie, Andrew Krukov ("Crackov"), Igor Muttik a Costin Raiu, pokud mám jmenovat pouze několik.

Dokumenty používající VBA5 (balík Microsoft Office 97) obsahují nejenom komprimované zdrojové makro kódy, ale také předkompilované verze kódu (nazývané jako p-kód, pseudokód), a rovněž spustitelný kód. Spustitelný kód je pokročilejší optimalizací p-kódu, která už dále běží bez dalšího ověřování, protože je uložena samostatně. Problematickým jevem však zůstává fakt, že při správných podmínkách je možné spustit každou z těchto tří forem kódu.

Některé antivirové produkty dokonce při opravě dokumentů způsobují jejich poškození. V jiných případech tyto produkty odstranily pouze jednu z těchto tří forem. Například – antivir odstranil p-kód, ale už ponechal kód zdrojový. Za běžných podmínek se p-kód snaží spustit jako první. Program VBA Editor je známý tím, že dekompilovaný p-kód zobrazuje jako "zdrojový" kód makra, namísto toho, aby použil opravdový zdrojový kód makra, který je uložen v dokumentu. Za určitých podmínek je možné, aby virus přežil i odstranění p-kódu. Toto nastane například tehdy, pokud je dokument vytvořen v Office 97, ale otevřen je pomocí Office 2000.

Většina virů se bez zdrojových kódů rozpadne, protože často používají funkce typu MacroCopy() pro kopírování zdrojového kódu. V jiných případech, jako například u červů, je makro funkční, neboť se již neodkazuje do svého zdrojového kódu.

V dalších případech může být spustitelný kód spuštěn bez svého zdrojového kódu a p-kódu v dokumentu. Pokud VBA projekt obsahuje spustitelný kód a je otevřen stejnou verzí aplikace Office jako je ta, ve které byl vytvořen, spustitelný kód se rozběhne a vše ostatní je ignorováno. Antiviroví výzkumníci například pozorovali chování viru X97M/Jini.A, kterému byl z hostitelského dokumentu odstraněn antivirovým programem jak zdrojový kód, tak i p-kód a tento byl označen jako "vyčištěný". Jenže virus

Počítačové viry – analýza útoku a obrana

83

se při spuštění ve verzi Office, ve které byl vytvořen26, opět rozběhl ze spustitelného kódu, čímž se tak mnohé viry mohly šířit dále. Život si vždy najde cestu, chtělo by se říct! Tenhle postup sice nepřežije každý virus, ale ty viry, které přežijí, se nemusí odkazovat na své zdrojové kódy nebo moduly. Namísto toho například zkopírují datové sešity oběti na pracovní plochu, kde zůstávají a přepisují soubory oběti svými upravenými soubory, které obsahují jejich kopie. A pochopitelně – právě tyto speciální případy představují pro antivirovou společnost hlavní problém. Viry, které existují pouze ve spustitelném kódu, jsou totiž obzvláště těžko detekovatelné. (Svůj podíl na této neutěšené situaci má i Microsoft poskytnutím neúplné specifikace svých formátů pod NDA26.)

3.7.1.7 Makro viry a multipartitní strategie Existuje i několik binárních virů, které se pokoušejí infikovat datové soubory, například dokumenty.

Tyto viry nejsou primárně závislé na interpretovaném prostředí.

Příkladem může být multipartitní virus W32/Coke, který speciálně infikuje globální šablony pomocí malého zaváděcího kódu. Tento zaváděcí kód nahraje do globální šablony polymorfní kód makra (diskutovaný v kapitole 7) z textového souboru. Důsledkem toho patří Coke mezi polymorfní binární viry, a současně i mezi makro viry. Polymorfní makro viry jsou obvykle nesmírně pomalé, neboť pro jejich spuštění je potřeba mnoho iterací. To, že je polymorfní engine pomalý, je již běžně uznávaný fakt. Protože však virus Coke generuje polymorfní virový makro kód do textového souboru za použití Win32 kódu, není polymorfní makro Coke ani zdaleka tak pomalé, jako většina polymorfních makro virů.

Jiné viry například nepotřebují Word pro infekci dokumentů Office. Takové viry jsou však poměrně vzácné a obvykle také velmi chybové. I přes fakt, že je formát souboru Wordu 6 dost komplikovaný, představuje parsování a modifikace touto cestou možné vstupní místo do systému. Virus W95/Navrhar například vkládá makro kód, který spouští binární soubor z konce souboru pro Word. Takto může Navrhar infikovat dokumenty, aniž by na samotném systému byl Word nainstalován.

3.7.1.8 Rovnice v Excelu Další sada problémů se objevila z toho důvodu, že Excel podporuje nejenom standardní makra, ale také i makra s rovnicemi (formula). Správně tušíte, že rovnice pro makra nejsou ukládány společně se standardními makry, a proto musí být nejprve nalezeno jejich umístění.

Viry, které k šíření potřebují jazyk pro rovnice programu Excel, bývají označovány značkou XF. Excelovská makra jsou uložena v prostoru pro moduly maker, rovnice pro Excel bývají uložena v prostoru pro makra Excelu 4. Proto tyto viry nejsou viditelné pomocí menu Tools/Macro a pro jejich nalezení je nutné speciální makro. První takový virus XF/Paix32 pochází z Francie.

3.7.1.9 Infekce uživatelských maker Většina makro virů šíří svoji vlastní sadu maker do dalších dokumentů. Existuje však možnost provést infekci modifikováním již existujících uživatelských maker pomocí techniky, která je podobná běžné infekci binárních souborů. V praxi se takto chová velmi malé množství virů. Je to hlavně z toho důvodu, že většina dokumentů žádná uživatelská makra neobsahuje, a proto je šíření takto parazitujících makro virů vážně omezeno. Nehledě na to, že ostatní makro viry při napadení obvykle smažou všechna uži-

84

Kapitola 3 – Prostředí škodlivého kódu

vatelská makra v objektech, které infikují. Tento typ makro virů nicméně představuje problém ohledně precizní detekce a odstranění viru.

3.7.1.10 Nové formáty souborů – XML (Extensible Markup Language) Společnost Microsoft v Office 2003 představila možnost ukládání dokumentů v textovém formátu XML. Toto způsobilo bolest hlavy většině vývojářů antivirů, neboť od této chvíle musí parsovat celé soubory, aby zde vypátrali vložené, zakódované OLE2 soubory a nalezli v nich potenciálně škodlivá makra.

V současnosti formát XML s vloženými makry33 podporují produkty Word a Visio 2003. Dokumenty těchto dvou programů původně neobsahovaly žádné pole v záhlaví indikující, zda-li jsou v nich obsaženy makra. Microsoft naštěstí po nátlaku antivirových firem změnil strukturu souboru pro program Word ještě před jeho oficiálním vydáním. U programu Visio 2003 se to bohužel nestihlo, takže antivirové firmy musí nutně parsovat všechny soubory, bez ohledu na přítomnost maker. Vzniká se tak problém v rychlosti skenování, který je patrný zejména v případě skenování po síti.

Poznámka Možnost infekce XML souborů byla autory virů zkoumána už před několika lety za použití kódu VBS (Visual Basic Skript). Původní myšlenka počítala s tím, že soubor XML bude obsahovat odkaz, který bude směřovat na soubor XSL (Extensible Stylesheet Language) uložený někde webu. Tato technika byla poprvé představena autorem virů jménem Rajaat a později implementována autorem vystupujícím pod jménem Benny ve viru W32/Press.

3.7.2 REXX viry na systémech IBM Společnost IBM má dlouhou tradici v implementaci prostředí interpretovaných jazyků. Příklady obsahují výkonný jazyk Job Control známý z dob sálových počítačů. Firma IBM představila skriptovací příkazový jazyk REXX z toho důvodu, aby jím podpořila jak rozsáhlé instalace založené na dávkách, tak i jednoduché instalační programy založené na menu. Není vůbec žádným překvapením, že tento jazyk byl použit i pro tvorbu nových skriptovacích virů. Je smutným faktem, že první z řady virů, který masově rozesílal e-maily (podobně jako později nechvalně proslulý červ CHRISTMA EXEC34) byl naprogramován právě ve skriptovacím jazyce REXX. Červ se mohl spouštět pouze na strojích podporujících interpret REXX, dále pouze na systémech IBM VM/CMS a musel být navíc připojen k síti. Tento červ byl naprogramován německým studentem informatiky35 v roce 1987.

Poté, co byl uživatelem spuštěn skript v jazyce REXX, červ CHRISTMA EXEC zobrazil vánoční stromek a zprávu uvedenou na obrázku 3.7. Ke spouštění na vzdálených strojích autor používal sociálního inženýrství. Uživatelé pak spokojeně následovali instrukce uvedené ve zdrojovém kódu skriptu. Červ pochopitelně hledal další uživatele v systému a pomocí CMS příkazu SENDFILE (nebo SF ve zkrácené notaci) jim posílal soubor CHRISTMA EXEC.

Počítačové viry – analýza útoku a obrana

Obrázek 3.7

85

Úryvek z červa CHRISTMA EXEC.

V jeden čas byly tyto viry rozšířeny v takovém množství, že IBM muselo pro jejich odstranění zprovoznit systém jednoduchého filtrování obsahu. Interpret REXX byl pozdější implementován i pro další operační systémy firmy IBM, jako třeba OS/2. Pro tento OS se ovšem objevilo pouze malé množství REXX virů.

3.7.3 DCL viry na DEC/VMS Červ Father Christmas se začal šířit v roce 1988. Tento červ si za cíl položil systémy VAX/VMS na SPANu a HEPNETu. Za použití protokolů DECNET namísto klasických TCP/IP známých z Internetu exploitoval chybu příkazu TASK0, která mu umožňovala z venku pracovat s procesy uvnitř systému.

Tento červ vytvářel své kopie pojmenované jako HI.COM. Přestože DOSovské COM soubory mají binární formát, jsou soubory DCL s koncovkou COM obyčejnými textovými soubory. Červ z napadených uzlů rozesílal e-maily, aniž by je používal k vlastnímu šíření. Útočil na vzdálené systémy použitím ob-

86

Kapitola 3 – Prostředí škodlivého kódu

vyklého přihlašovacího jména a hesla a poté se kopíroval, pěkně řádek po řádku (151 řádků) na vzdálený stroj.

Pak červ exploitoval TASK0 pro spuštění své vzdálené kopie. Konkrétně červ použil příkaz SET PROCESS/NAME, který mu umožňoval spuštění na vzdáleném systému jako proces MAIL_178DC36. Father Christmas pak rozesílal uživatelům vzdálených počítačů následující vtipnou zprávu: $ MAILLINE0 = "HI," $ MAILLINE1 = "" $ MAILLINE2 = " HOW ARE YA ? I HAD A HARD TIME PREPARING ALL THE PRESENTS." $ MAILLINE3 = " IT ISN'T QUITE AN EASY JOB. I'M GETTING MORE AND MORE" $ MAILLINE4 = " LETTERS FROM THE CHILDREN EVERY YEAR AND IT'S NOT SO EASY" $ MAILLINE5 = " TO GET THE TERRIBLE RAMBO-GUNS, TANKS AND SPACE SHIPS UP HERE AT" $ MAILLINE6 = " THE NORTHPOLE. BUT NOW THE GOOD PART IS COMING." $ MAILLINE7 = " DISTRIBUTING ALL THE PRESENTS WITH MY SLEIGH AND THE" $ MAILLINE8 = " DEERS IS REAL FUN. WHEN I SLIDE DOWN THE CHIMNEYS" $ MAILLINE9 = " I OFTEN FIND A LITTLE PRESENT OFFERED BY THE CHILDREN," $ MAILLINE10 = " OR EVEN A LITTLE BRANDY FROM THE FATHER. (YEAH!)" $ MAILLINE11 = " ANYHOW THE CHIMNEYS ARE GETTING TIGHTER AND TIGHTER" $ MAILLINE12 = " EVERY YEAR. I THINK I'LL HAVE TO PUT MY DIET ON AGAIN." $ MAILLINE13 = " AND AFTER CHRISTMAS I'VE GOT MY BIG HOLIDAYS :-)." $ MAILLINE14 = "" $ MAILLINE15 = " NOW STOP COMPUTING AND HAVE A GOOD TIME AT HOME !!!!" $ MAILLINE16 = "" $ MAILLINE17 = " $ MAILLINE18 = "

MERRY CHRISTMAS" AND A HAPPY NEW YEAR"

$ MAILLINE19 = "" $ MAILLINE20 = "

YOUR

FATHER CHRISTMAS"

3.7.4 Shell skripty na UNIXu (csh, ksh a bash) Většina systémů UNIX podporuje skriptovací jazyky, běžně nazývané jako shell skripty. Ty jsou používány při instalacích a dávkovém zpracování. Proto je běžné, že je viry na systémech UNIX často používají pro svoji vlastní instalaci. Shell skripty mají výhodu ve své schopnosti fungovat na různých verzích systémů UNIX. Přestože mezi většinou systémů UNIX nenalezneme binární kompatibilitu, shell skripty mohou být útočníkem využity pro překlenutí tohoto problému. Shell skripty mohou navíc používat standardní nástroje systému, jako je například GREP, což funkčnost těchto virů dále výrazně rozšiřuje.

Shell skripty mohou implementovat většinu známých infekčních technik, jako je přepisování nebo vkládání před a za programy. V roce 2004 se objevili červi jako SH/Renepo.A, kteří používali bash skript pro zkopírování svého kódu do adresáře StartupItems na připojených discích systému MAC OS X. Toto pravděpodobně naznačuje obnovený zájem o vývoj červů pro MAC OS X. Navíc viry typu Renepo vystavují systémy MAC OS X celé řadě dalších útoků tím, že vypínají interní firewall, spouští oblíbený crackovač hesel John The Ripper, a pro potřeby útočníků také vytvářejí nové přístupové účty. Je ovšem

Počítačové viry – analýza útoku a obrana

87

potřeba zmínit, že podobné útoky v současnosti vyžadují root práva. (Dá se však předpokládat, že MAC OS X bude v budoucnu rovněž cílem útoků založených na vzdálené exploitaci.)

3.7.5 VBScript viry na systémech Windows Skriptovací viry pro Windows se objevily okamžitě po úvodní fázi útoku makro virů. Červ VBS/LoveLetter.A@mm se po světě velkou rychlostí šířil už v květnu roku 2000. LoveLetter dorazil k příjemci s krátkou zprávou a předmětem "ILOVEYOU", jak je to patrné z obrázku 3.8. Příloha e-mailu měla "dvojitou příponu". "Druhá" přípona byla VBS, která byla nezbytná pro spuštění přílohy jako skriptu programu Visual Basic. Tato "druhá" přípona však byla díky výchozímu nastavení systému Windows "Skrýt příponu souborů známých typů" neviditelná. Mnohý začínající uživatel si tak myslel, že spouští obyčejný a neškodný textový soubor, "milostné psaníčko".

Obrázek 3.8

Dostali jsme "milostné psaníčko".

Při spuštění přílohy je pomocí interpretu skriptů WSKRIPT.EXE spuštěn soubor VBS. Červi založení na VBS skriptech a hromadném rozesílání e-mailů obvykle používají funkce Outlook MAPI pomocí CreateObject ("Outlook.Application"), následovanou metodou NameSpace ("MAPI") sbírající e-mailové adresy pomocí AddressLists(). Poté červi hromadně rozesílají sami sebe jako přílohu pomocí metody Send(). Takto dostalo mnoho uživatelů zprávu od lidí, které osobně znali. Proto byli také dostatečně zvědaví na to, aby spustili přílohu e-mailu – a často více než jednou.

VBS viry těží z rozšířené funkčnosti objektů ActiveX. Ty totiž mají přístup k systémovým objektům, dalším e-mailovým aplikacím a lokálně nainstalovaným objektům ActiveX.

3.7.6 Dávkové viry Dávkové (batch) viry nebyly v dobách DOSu nikdy moc úspěšné. K vytvoření skutečně se šířícího viru byly podniknuty mnohé kroky, avšak ani jeden z nich nebyl skutečně úspěšný. Ale i tak byly vyvinuty a demonstrovány běžné způsoby infekce. Například dávkové soubory mohou být napadeny technikou vkládající kód na začátek souboru, vložením instrukce goto a následným přidáním dalších řádků na konec souboru.

Dávkové viry bývají často zkombinovány s binárními útoky. Virus BATVIR používá techniku přesměrování výstupu příkazu "echo" do skriptu programu DEBUG – takto je virus textovým dávkovým příkazem začínajícím takto: rem [BATVIR] '94 (c) Stormbringer [P/S]

88

Kapitola 3 – Prostředí škodlivého kódu

Toto je pak následováno sadou příkazů echo vytvářejících samotný batvir.94 soubor pomocí skriptů programu DEBUG. Program DEBUG obdrží G – GO příkazy prostřednictvím skriptu a spustí binární virus, aniž by jej předtím vytvářel v novém souboru.

Virus BAT/Hexvir používá podobnou techniku, ale jinak jednoduše "echuje" binární kód do souboru, který pak spustí pomocí souboru DOS COM pro následné vyhledání a infikování dalších souborů.

Jiné šikovné dávkové viry používají příkazy FOR % IN () pro vyhledávání souborů s příponou BAT, které pak vkládají do komprimované podoby pomocí programu PKZIP. Virus BAT/Zipbat při spuštění napadených dávkových souborů používá program PKUNZIP pro rozbalení nového souboru V.BAT, který infikuje další soubory tím, že se umísťuje přímo do nich, opět v zapakované formě. Členové rodiny BAT/Batalia používají místo programů PKZIP a PKUNZIP program ARJ. Batalia navíc používá náhodné hesla pro svoji komprimaci do dávkových souborů.

A podobně jako BAT/Zipbat, rodina virů BAT/Polybat rovněž používá aplikace PKZIP a PKUNZIP pro komprimaci a dekomprimaci svého kódu. Polybat je navíc polymorfním virem. Vkládá totiž nadbytečné struktury složené ze znaků % a &, které jsou během běžného zpracování ignorovány. Například příkaz ECHO OFF může být zapsán tímto způsobem: @ec ec%&%h h%&%o o o%&%f f%&%f @e e%&%ch ch%o o&% %&o o%f f%f f&%

Dávkové viry (nebo alespoň multipartitní viry s dávkovou částí) představující neustále se zvyšující hrozbou pro systémy Windows. Příkladem může být rodina BAT/Mumu, která je velmi úspěšná ve firemním prostředí za pomoci binárních sharewarových nástrojů (jakou je například PSEXEC) v kombinaci s BAT souborem, který je poháněný kódem viru.

Speciální verze dávkových jazyků jako třeba BTM soubory ve 4DOSu a 4NT produkty – abychom jmenovali alespoň pár – jsou dalšími nástroji použitými tvůrci útočného a škodlivého software.

3.7.7 Viry ve skriptech programů mIRC, PIRCH Programy pro rychlou komunikaci mezi uživateli, jakým je například mIRC, podporují skriptovací jazyk pro definování uživatelských akcí a zjednodušení komunikace mezi uživateli. Skriptovací jazyk umožňuje spustit příkazy kdykoliv, když se do konference připojí další člen. Příkaz je často uložen v souboru skript.ini v systémové složce programu mIRC. IRC červi se pak snaží přepsat tento soubor INI vlastním souborem, který rozesílá kopie červa dalším uživatelům IRC. Příkazový skript podporuje příkaz odesílání /dcc. Tento příkaz může být použit k odeslání souboru účastníkovi, který je připojen k danému kanálu.

3.7.8 SuperLogo Viry V dubnu roku 2001 se objevil červ LOGO a masově se rozesílal antivirovým firmám. Nikdy ovšem nedosáhl velkého rozšíření. Jeho autor se představuje jako Gigabyte. Gigabyte má ve svém rejstříku tvorbu dalšího škodlivého software a je autorem několika mIRC červů. Jak uvidíte, pokusil se použít znalosti z oblasti IRC pro vytvoření červa v prostředí Logic37. Současný červ je vytvořen v programu Super

Počítačové viry – analýza útoku a obrana

89

Logo, který je reinkarnací starého jazyka Logo pro platformy Windows, prohlašující o sobě, že je "platformou Windows pro děti".

V roce 1984 jsem viděl několik implementací jazyka Logo pro různé 8bitové počítače. Náš školní 8bitový počítač HT 1080Z – což byl na Z80 založený klon TRS-80 vyráběný v Maďarsku – měl nejvyšší hranici rozlišení 128x48 bodů v černé a bílé barvě. Přestože jsme tomu tehdy nevěnovali pozornost, zabudovaný jazyk Basic pro HT 1080Z byl v roce 1980 vytvořen společností Microsoft.

Jazyk Logo především představoval možnost kreslení pomocí želvy. Želva je zde tužkou a jak její hlava může měnit směr, je možné naprogramovat cestu tužky. Takže v programu Super Logo objevíme následující příkazy: HIDETURTLE (schovej želvu), FORWARD (dopředu), PENUP (zapnout tužku), PENDOWN (vypnout tužku), WAIT (čekej) atd.

Sady příkazů mohou být uspořádány jako pod-rutiny a uloženy v projektu programu Logo s příponou LGP. Formát tohoto souboru představuje jednoduchý binární formát, nicméně příkazy a proměnné jsou snadno čitelné a uloženy jako řetězce ve stylu jazyka Pascal. Projektový soubor je možné nahrát a spustit pomocí interpretu programu Super Logo. Původní jazyk Logo je v programu Super Logo rozšířen dostatečně na to, aby mohl soupeřit s dalšími implementacemi. Poradí si s mnohonásobnými grafickými objekty (prohlédněte si milou želvičku na obrázku 3.9), přičemž umožňuje jejich pohyb po obrazovce pomocí myši.

Obrázek 3.9

Ikonka želvy.

Snadno si hned uvědomíme, že jazyk Super Logo nepodporuje e-maily nebo vložené spustitelné soubory, stejně jako nepodporuje spawning dalších spustitelných souborů a skriptů. Program Super Logo nicméně podporuje příkaz PRINTTO "XYZ", kde XYZ může obsahovat kompletní cestu k souboru.

Takto může program v jazyce Logo modifikovat libovolný soubor, jako třeba winstart.bat, přepisujíce jeho obsah něčím podobným tomuto: @cls @echo You think Logo červs don't exist? Think again!

Pochopili jste? Pokud je projekt logic.lgp načten a vykonán, červ vykreslí na obrazovce slovo LOGIC doprovázené krátkou zprávou, jak je to uvedeno na obrázku 3.10.

90

Obrázek 3.10

Kapitola 3 – Prostředí škodlivého kódu

Payload červa Logic.

Červ se nejprve ujistí, že je v systémové složce Windows vytvořen soubor STARTUP.VBS, který je při dalším restartu systému Windows automaticky spuštěn. Červ se také pokusí modifikovat zástupce (pokud nějaký je) některých obvyklých aplikací Windows, jako je například notepad.exe, za účelem dalšího spuštění VBS skriptu.

Tento VBS soubor zajišťuje poslání červího souboru logic.lgp na prvních 80 kontaktů z adresáře Outlooku. Toto je standardní způsob šíření VBS skriptů, který má ovšem celou sadu drobných chyb v implementaci. V roce 2004 byl Gigabyte zatčen belgickou policií. Nyní čelí obvinění z trestné činnosti, přičemž trestem může být nejenom velká pokuta, ale také uvěznění.

3.7.9 JScriptové viry Jedním z důvodů, proč se doporučuje vypnout podporu JScriptu v internetových prohlížečích (jako je třeba Internet Explorer) jsou právě JScriptové viry. Tyto viry klasicky zneužívají funkce pomocí komunikačních objektů ActiveX. K těm přistupují obdobným způsobem jako skripty VBS. Například úplně první přepisující JScriptové viry přistupovaly k souborovému systému pomocí metody CreateObject ("Scripting.FileSystemObject"). Tento druh viru byl vytvořen kolem roku 1999 autorem jménem Jacky, který je členem virové skupiny Metaphase.

File System Object nabízí útočníkům vysokou flexibilitu. Útočník může třeba pomocí metody CopyFile() přepisovat soubory. Takto pracují JScriptové viry. Samozřejmostí jsou pokročilejší útoky pomocí funkcí OpenTextFile(), Read(), Write(), ReadAll() a Close(). JScriptové viry tak mohou mít funkčnost, která je svojí komplexností podobná VBS virům, při použití mírně odlišného zápisu.

Počítačové viry – analýza útoku a obrana

91

3.7.10 Perlovské viry Perl představuje extrémně populární skriptovací jazyk. Interprety jazyka Perl jsou obvykle instalovány na nejrůznějších operačních systémech, Win32 nevyjímaje. Autor virů jménem SnakeByte má na svědomí celou řadu virů pro skriptovací jazyk Perl.

Perlovské skripty nabízí v kompaktní formě širokou funkčnost. Útočníci tak mohou vytvořit nejenom zakódované a metamorfní viry, ale v mnoha případech i vstupní bod pro ještě obskurnější způsoby útoků. Funkce open(), print a close() jsou v současnosti nejčastěji používanými příkazy, společně s funkcí foreach() používanou k nalezení cílového souboru.

Následující sekvence Perlu načte svůj kód do proměnné CurrentContent: open(File,$0); @CurrentContent=<File>; close(File);

Perl je obzvláště snadným nástrojem pro tvorbu virů, protože patří mezi výkonné skriptovací jazyky pro zpracování obsahu souboru.

3.7.11 Červi WebTV napsaní v JellyScriptu a vložení do HTML e-mailů Microsoft WebTV je speciální zařízení umožňující prohlížení webu pomocí televizních obrazovek.

V červenci 2002 se objevil nový škodlivý WebTV červ, který se na první pohled jevil jako trojský kůň.

Payload tohoto červa překonfiguroval nastavení přístupového čísla k síti WebTV (číslo vytáčeného připojení) na číslo 911 (americká analogie nouzového čísla 112), čímž tak vytvořil DoS útok.

HTML (Hypertext Markup Language) soubory WebTV mohou v Internet Exploreru ve WebTV používat parametr HREF (URL odkazu) uvnitř značek <script> a </noscript>. Hodnota parametru HREF klasicky vede na nějakou webovou stránku dostupnou na internetu, ale v případě JellyScriptu ve WebTV byly tyto parametry použity pro samotné nastavení WebTV. Jak už bývá zvykem, tyto příkazy nebyly oficiálně zdokumentovány, nicméně se někteří výzkumníci snažili zjistit více informací WebTV a výsledky svého výzkumu, včetně použitelných příkazů, publikovat. Škodlivý program NEAT, později identifikovaný jako červ, používal příkaz sendpage pro odeslání HTML e-mailu s červem dalším uživatelům sítě WebTV. E-mail byl rozesílán z různých falešných adres, jako např. Owner_, minimoo, masonman atd.

Na zařízení oběti červ rovněž otevíral mnoho vyskakovacích oken s reklamami. To dělal ještě předtím, než použil příkaz ConfirmPhoneSetup?AccessNumber pro nastavení vytáčeného čísla na 911, čímž tak přetížil linku záchranné služby pomocí DoS útoku.

3.7.12 Viry pro Python Python je extrémně šikovný programovací jazyk. Na rozdíl od shell skriptů, které mohou být limitovány především různými problémy s rychlostí, je Python rychlý a modulární. Díky podpoře většího množství základních datových typů může být Python použit k řešení rozsáhlých úkolů. Obsahuje moduly podporující systémová volání, operace I/O, sockety a mnoho dalších věcí.

92

Kapitola 3 – Prostředí škodlivého kódu

Přestože nejsou viry pro Python příliš obvyklé, existuje několik virů napsaných v tomto skriptovacím jazyku. Tyto viry typicky kombinují funkce open(), close(), read() a write() pro nalezení souborů a pomocí funkce listdir() se rozšiřují do dalších souborů. Tento typ virů je asi tou nejjednodušší představitelnou technikou útoků pro Python, jazyk samotný však zvládá implementovat mnoho různých druhů infekční strategie.

3.7.13 VIM viry Následovníkem editoru VI, známého z prostředí UNIXu, je VIM (VI IMproved, vylepšený). Na rozdíl od VI pracuje VIM na systémech Windows, Macintosh, Amiga, OS/2, VMS, QNX a mnoha dalších.

VIM je textový editor obsahující všechny příkazy a funkčnost původního VI a přidávající mnohé další.

Mezi mnoha novými vlastnostmi je i podpora silného skriptovacího jazyku, který už byl některými autory virů použit k tvorbě červů.

3.7.14 EMACS viry Podobně jako u programu VIM, i novější verze editoru EMACS podporují skriptování. Tento typ viru sice není běžný, nicméně pro toto prostředí existují různé virové koncepty.

3.7.15 TCL viry TCL (Tool Command Language) je přenositelný skriptovací jazyk, který může běžet na systémech, jako jsou HP-UX, Linux, Solaris, MAC a dokonce Windows. TCL velmi podobný jazyku Perl. TCL skripty jsou spouštěny pomocí interpretu tclsh.

První virus implementovaný pro TCL (vyslovuje se jako "tikle") byl Darkness, velmi jednoduchý virus vytvořený tvůrcem Gigabyte v roce 2003. TCL podporuje funkce foreach(), open(), close(), gets() a puts(), což je vše, co skriptovací TCL viry potřebují k šíření.

3.7.16 PHP viry PHP (hypertext preprocessor) je otevřený skriptovací jazyk pod open-source. Je dobře připraven pro vyvíjení webových aplikací a je vkládán do stránek HTML. PHP se liší od klientského skriptování, jakým je například JScript, protože PHP běží na straně serveru, a nikoliv u klienta. PHP může být také použito i z příkazové řádky, bez přítomnosti jakéhokoliv serveru či browseru.

Virus PHP/Caracula byl vytvořen autorem Xmorfic, členem skupiny BCVG v roce 2001. Virus se šíří přepisováním a vytvářením mIRC skriptů, které zajišťující šíření červa.

PHP viry typicky používají funkce fopen(), fread(), fputs(), fclose() k zápisu do nových souborů, které vyhledávají pomocí infekčních technik přímé akce za použití opendir(), readdir(), closedir(), v kombinaci s funkcí file_exists().

Existují i příklady polymorfních PHP virů, jako je například PHP/Feast, vytvořený autorem jménem Kefi v roce 2003. Feast vyhledává soubory k přepsání a následně je přepisuje vylepšenou verzí sama sebe. Dá se říci, že v podstatě každá další verze viru je mutací náhodné sekvence znaků.

Počítačové viry – analýza útoku a obrana

93

3.7.17 MapInfo viry Prostředí MapInfo vyvinuté firmou Geo-Information Systems není příliš rozšířenou aplikací. Je používáno pro geografickou analýzu a mapování. Virus MPB/Kynel38 však demonstruje, že i tato platforma může být použita vytváření virů. Kynel byl vytvořen ruskými autory na konci roku 2003.

MapInfo Professional má vlastní vývojové prostředí nazvané MapBasic, což je jazyk podobný Basicu.

MapBasic je velmi schopný a jak se dá předpokládat, obsahuje Open, Close, Read a Write, a to jak pro ASCII, tak i pro binární soubory. Navíc podporuje API volání z dalších souborů DLL, dynamickou výměnu dat (DDE, dynamic data exchange), linkování objektů a vkládání (OLE). Po kompilaci je vytvořen nový spustitelný soubor – MBX, který je pojmenován podle MapBasic eXecutable. Jak se dá předpokládat, tyto soubory se dají pouze spustit v prostředí programu MapInfo.

Virus MPB/Kynel infikuje nové tabulky. Vyhledává další tabulky pokaždé, když je volána funkce WinChangedHandler(). Funkce WinChangedHandler() je volána pokaždé, když uživatel provede libovolnou změnu v dokumentu. Virus je zavěšen na tuto funkci a využívá tento okamžik pro vytvoření své kopie do nově spočítaných tabulek, jako tablename.mif. Poté vloží řádek "Run Application" do spustitelného MBX do TAB souboru dokumentů MapInfo. Takto je zajištěno, že soubor MBX bude otevřen pokaždé, kdy bude otevřen infikovaný dokument.

Aplikace MapInfo je dostupná ve verzi jak pro platformu Windows, tak i pro Macintosh. Není to příliš obvyklé prostředí pro tvorbu virů, ale jak jsme viděli na příkladě Super Loga, demonstruje to zájem autorů virů o jakoukoliv platformu, která může sloužit jako potenciální cíl.

3.7.18 ABAP viry na SAPu Prvním virem, který se pokoušel infikovat SAP, byl virus ABAP/Rivpas, napsaný v dubnu 2002. Jedná se o virus potvrzující koncept založený na skriptovacím jazyce Advanced Business Application. Tento výtvor měl několik úmyslných chyb a nedostal proto šanci se rošířit. Ovšem verze s opravenými chybami na sebe nenechaly dlouho čekat – a zde už se jednalo o skutečné viry. Pomocí dvaceti řádků kódu se virus replikuje v databázích kopírováním z jedné do druhé.

3.7.19 Viry pro soubory nápovědy Windows – když zmáčknete F1...

Velmi silným a překvapivě nepopulárním cílem virové infekce jsou soubory nápovědy systému Windows. Soubory nápovědy Windows jsou v binárním formátu a obsahují sekci skriptů. Skripty mají přístup k volání API Windows. Většina Help virů injektuje malý skript do adresáře obsahujícího HLP soubory. Tento skript pak bude vykonán při příštím spuštění souboru nápovědy. Důsledkem toho se virus spustí pouhým zmáčknutím klávesy F1, za předpokladu, že v dané aplikaci je s touto klávesou spojen (infikovaný) soubor nápovědy.

Hlavním trikem je definice funkcí pro vlastní použití, jako je například EnumWindows() souboru USER32.DLL. Pro vysvětlení, tuto techniku používá například virus Dream pro infekci souborů nápovědy systému Windows. Řádek skriptu RR ('USER32.DLL',' EnumWindows','SU') definuje zpětné volání EnumWindows() pro použití. Poté je skriptem použito volání EnumWindows(tělo-viru), který vykoná "řetězec" těla viru

94

Kapitola 3 – Prostředí škodlivého kódu

prostřednictvím zpětného volání. Vykonávání pak už může probíhat v nativním kódu, mimo kontextu skriptu.

Prvním virem, který napadal soubory nápovědy, byl 32bitový polymorfní virus W95/SK39,vytvořený v Rusku. Na rozdíl od viru Demo, virus SK používá funkci WinExec() pro spuštění sady příkazů command.com /c echo pro vložení kódu do binární formy pro spuštění mimo HLP soubor v kořenovém adresáři. Prvním nativním infektorem souborů nápovědy byl virus HLP/Demo, který se rovněž dokázal replikovat z jednoho souboru nápovědy do druhého.

3.7.20 JScriptové hrozby v souborech Adobe PDF Formát PDF je používán produkty Adobe Acrobat. V roce 2003 se objevil virus {W32,PDF}/Yourde infikující PDF soubory s využitím exploitace JScriptu. Virus vyžaduje kompletní instalaci programu Adobe Acrobat, protože je závislý na ukládání infikovaného souboru uživatelem. (Externí uložení infikovaného souboru není pomocí programu Adobe Acrobat možné, nehledě na to, že prohlížeč Adobe Acrobat Reader nedisponuje schopností ukládat PDF soubory.)

JSkript je Acrobatem spouštěn automaticky, aniž by se spoléhal na externího interpreta, jakým je například Windows Scripting Host. Tato zranitelnost je závislá na konkrétní verzi programu Acrobat.

3.7.21 Závislost na AppleScript AppleScript je na systémech Macintosh používán pro podporu lokálního skriptování. Není proto překvapením, že některé hrozby se mohou šířit pouze za předpokladu, že je nainstalován AppleScript. Například červ AplS/Simpsons@mm byl napsán v AppleScriptu. Poté, co je spuštěn, pošle pomocí programu Outlook Express nebo Entourage svoji kopii každému uživateli, který je uveden v adresáři.

Samotný červ se nešíří příliš divoce. Nicméně hrozby využívající AppleScript vystavují uživatele MACů podobným bezpečnostním problémům, jako hrozby, které využívající další výkonné skriptovací jazyky, jako je například VBS v prostředí Windows.

3.7.22 Závislost na ANSI Počítače IBM PC představily ovladače ANSI.SYS, které vyplňují potřeby mnoha uživatelů poskytováním schopnosti překonfigurovat klíčové funkce pomocí únikových (ESC) sekvencí. Tyto sekvence bývají obvykle uloženy v souboru s koncovkou ANS. ESC sekvence mohou začínat zvláštním únikovým kódem (přístupným podržením klávesy Alt a vypsáním40 na numerické klávesnici).

Kdykoliv soubor CONFIG.SYS obsahuje řádek DEVICE=ANSI.SYS, jsou ESC sekvence k dispozici. Například jednoduchá ANSI sekvence může takto předefinovat klávesu N jako Y a klávesu n jak y. Důsledkem toho pak bude uživatel zadávat nesprávné odpovědi při různých výzvách aplikací. Toho je dosaženo následujícím způsobem: ESC [78;89;13p ESC [110;121;13p

Tento druh předefinování je pochopitelně možné použít i pro jiné klávesy. Klávesa Enter může být například předefinována na příkaz del *.* nebo na příkaz format c:. ANSI sekvence mohou být rovněž použity pro předefinování celých příkazů.

Počítačové viry – analýza útoku a obrana

95

3.7.23 Hrozby v ActionScriptu Nováčkem na scéně škodlivého software jsou škodlivé programy využívající ActionScript. Virus LFM používá ActionScript souborů Flash pro vytvoření a spuštění vykonatelného COM souboru v DOSu. Podobné hrozby jsou ale dost omezeny díky různým závislostem.

Například virus LFM41 potřebuje být stažen na lokální počítač z nějaké webové stránky. Soubory může napadat pouze tehdy, pokud byl z webové stránky uložen do adresáře, který obsahujíce doposud nenapadené soubory a navíc za podmínky, že bude korektně fungovat externí soubor V.COM.

3.7.24 Hrozby skriptů HyperTalk "Od pátého stupně je potřeba naučit lidi, jak používá počítač z pozice pána a nikoliv otroka. Je skvělý způsob, jak začínat s výukou."

– Steve Wozniak HyperCard je všestranné prostředí podporující skriptovací jazyk jménem HyperTalk. Vytvořen Billem Atkinsonem představuje HyperTalk jeden z nejvíce lingvisticky zaměřených skriptovacích jazyků vůbec. Proto vás asi těžko překvapí, že v něm byly napsány jedny z nejstarších počítačových virů. První virus byl v prostředí skriptů HyperTalk napsán zhruba v roce 1988 a jmenuje se Dukakis.

Spuštění skriptů HyperTalk je založeno na ovladačích událostí asociovaných se jménem v zásobníku.

Skripty jsou uloženy v datových souborech HyperCard, které se nazývají jako zásobníky (stack), přičemž jsou v binárním formátu. Uvnitř zásobníků je však kód skriptů čistě textový.

Například pro otevření HyperCard zásobníku je vyvolán ovladač událostí openStack. To je docela podobné zpracovávání maker produkty Microsoft Office, přestože je HyperCard mnohem více než pouhým textovým editorem s podporou skriptování. Může být použit k tvorbě nejrůznějších projektů s menu a databázovým front-endem pro záznamy v databázi, přičemž různé zásobníky mohou sdílet své funkce. HyperCard rozšířil možnosti z jednoduše použitelných systémů na jednoduše programovatelné prostředí.

Skriptovací kód HyperTalku je intepretován mezi dvěma tagy. První tag začíná klíčovým slovem on.

Druhý tag končí klíčovým slovem end. Zde je příklad použití: on openStack ask "What is your name?" put it * it into field "Name" end openStack

HyperCard byl vyvinut ještě před Visual Basicem firmy Microsoft. Podobně jako produkty Microsoft Office obsahuje globální šablonu. HyperCard také podporuje tzv. "domácí zásobník", který obsahuje celou řadu užitečných skriptů. Většina HyperCard virů infikuje tento domácí zásobník tak, že zkopírují sami sebe do něj za použití několika klíčových slov. Jakmile je to dokončeno, virus se může zkopírovat do všech nově vytvářených a otevíraných zásobníků. Jakýkoliv zásobník může být použít jako domácí zásobník, pokud je jeho jméno home.

96

Kapitola 3 – Prostředí škodlivého kódu

Virus Dukakis používá následující řádky kódu pro výběr svého těla pro vytvoření nové kopie: put the skript of stack "home" into temp2 get offset (""-** The HyperAvenger **-,"temp2) put char it to it+2426 of temp2 into theCode

Tato část skriptu vyhledává offset, kde začíná v domácím zásobníku kód viru, přičemž kopíruje své tělo (2426 bajtů) z této lokace do proměnné theCode. Virus poté už potřebuje jenom zkopírovat obsah theCode do dalšího zásobníku. Tento zásobník slouží jako reference na aktuálně otevřený zásobník. K jeho obsahu můžeme přistupovat použitím příkazu put.

Další typy virů pro HyperCard je možno nalézt na platformě Mac; mezi nejznámější patří Merry Xmas a rodina virů 3 Tunes.

3.7.25 Skriptovací viry pro AutoLisp Skriptovací viry pro HyperTalk jsou snadné na čtení a pochopení – skriptovací hrozby AutoLispu jsou naopak hůře identifikovatelné. Několik skriptovacích virů, jako například Pobresito42 a ALS/Burstead43 používají schopnost skriptování AutoLisp v prostředí AutoCADu.

Poznámka Novější verze programu AutoCAD navíc podporují VBA.

Pobresito byl vytvořen v průběhu léta roku 2001. Burstead se objevil mnohem později, v prosinci 2003 ve Finsku a dokázal infikovat počítače několika čelních firem provozujících moderní verze AutoCADu. AutoCAD je poměrně drahý software, a zdaleka není používán v takovém měřítku jako jiná prostředí skriptovacích jazyků.

Skripty pro AutoLisp jsou ukládány v textových souborech s příponou LSP. Virus Burstead.A vyhledává s použitím funkce findfile umístění souboru AutoCADu pojmenovaného jako base.dcl: (setq path (findfile "base.dcl"))

To se děje za účelem nalezení adresáře, ve kterém je možno nalézt další LISP soubory. Další virové útoky se snaží o modifikaci souborů obsahujících příkaz load, aby nahrály svůj vlastní LSP soubor.

Pokud je takto modifikovaný soubor LSP spuštěn, virus může prostřednictvím příkazu load získat kontrolu: (load "foobar")

Slovo "foobar" zde představuje název souboru s příponou LSP umístěného v obvyklém adresáři.

Počítačové viry – analýza útoku a obrana

97

AutoLisp povoluje funkce zapisující do řádků (write-line functions), které mohou útočníci využít pro nejrůznější infekční techniky.

3.7.26 Závislost na registru Některé viry mají schopnost infikovat soubory registru systému Windows. Registr je centrální úložná databáze na systémech Windows. Dřívější verze systému Windows používaly k ukládání vlastního nastavení především soubory INI. Na moderních systémech Windows existuje centrální databáze registru, pojmenovaná jako úl (hive), která ukládá jednotlivá nastavení do stromové struktury.

Registr má zajímavou schopnost ukládat cesty k souborům pro jejich systémové spuštění při startu pod několika speciálními pod-položkami úlu, jakými je například HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RUN. Tyto klíče pak bývají cílem útoků nejrůznějšího škodlivého kódu. Další lokace registru rovněž poskytují autorům virů výchozí základ pro útoky. Například rodina červů W32/PrettyPark modifikuje klíč registru, který je uložený v HKEY_CLASSES_ROOT\exefile\shell\open\command, pro své spuštění v okamžiku, když uživatel spustí libovolný EXE soubor. Soubor, který se uživatel pokouší spustit, je pochopitelně spuštěn – ale až poté, co je spuštěn červ.

Na registru závislé viry používají podobné klíče například ke vkládání referencí na systémové příkazy pro pozdější spuštění. Položky registrů obsahující instalační soubory jsou uloženy v textové formě a obsahují informace o klíčích a hodnotách instalace skrz Regedit. Takové viry jsou implementovány jako jednotlivé položky v REG souborech. Regedit umí interpretovat příkazy obsažené v REG souborech – důsledkem toho je fakt, že nové položky budou uloženy v registru pro pozdější spuštění. Škodlivé položky používají standardní systémové příkazy s přidanými parametry, aby mohly prohledávat další REG soubory jak na lokálních, tak i síťových úložištích a modifikují je, aby obsahovaly příkazový řetězec vedoucí do REG souborů. Tato technika je založena na faktu, že dávkové příkazy systému DOS mohou být spouštěny z registru.

3.7.27 Závislost na PIF a LNK Viry také mohou infikovat soubory PIF (program information files) a soubory LNK (link files) systému Windows. Soubory PIF jsou vytvářeny vždy, když vytvoříte zástupce nebo modifikujete vlastnosti programu MS-DOS, což vám umožní nastavit výchozí parametry pro spouštění – jako například velikost fontu, barvy obrazovky a alokaci paměti. Soubory PIF jsou též používány pro uložení cesty ke spustitelnému souboru.

Některé viry útočí na soubory PIF modifikací interních odkazů, které směřují na spustitelný soubor.

Obvyklý přístup typického viru pro PIF je spustit se pomocí příkazů spouštěných skrz command.com, za použití uvedené cesty odkazů. Viry používají příkaz copy ke kopírování souborů PIF na jiné místa na lokálním disku, jako například do adresáře Windows, do adresáře programu mIRC nebo na různé adresáře pro P2P. Mohou se také zkopírovat do jiných síťových zdrojů.

Na soubory LNK (link shortcut files) systému Windows 95 a vyšších se dá zaútočit podobným způsobem jako na soubory PIF.

98

Kapitola 3 – Prostředí škodlivého kódu

3.7.28 Makro viry programu Lotus Word Pro Jinou třídu útoků makro virů představují dokumenty programu Word Pro od společnosti Lotus z kancelářského balíku Lotus SmartSuite. Například virus LWP/Spenty se umí šířit pouze v čínské verzi programu Word Pro. Virus infikuje otevírané soubory tak, že se zavěsí na makro DocumentOpened() a DocumentedCreated(). Bezpečnostní nastavení dokumentu je pozměněno tak, že jeho heslo je nastaveno na 720401. Tímto způsobem se virus snaží zabránit modifikacím již infikovaných objektů.

Virus Spenty se v roce 2002 široce rozšířil po celé Číně. Spenty tak představil problém v parsování souborů Word Pro antivirovými produkty. Program Word Pro používá makro jazyk podobný skriptování.

3.7.29 Viry dokumentů AmiPro Viry nenapadají příliš často dokumenty programu AmiPro a mají k tomu dobrý důvod. Narozdíl od většiny textových editorů ukládá AmiPro dokumenty a makra do dvou oddělených souborů. Dokumenty jsou uloženy v souborech s koncovkou SAM, zatímco makro soubory mají koncovku SMM. Viry pro AmiPro musí tyto dva soubory propojit v okamžiku otevření souboru SAM, a zajistit tak provedení souborů SMM. Virus APM/Greenstripe se skládá ze čtyř funkcí: Green_Stripe_Virus(), Infect_File(), SaveFile() a SaveAsFile(). Funkce SaveFile() a SaveAsFile() jsou zavěšeny uvnitř funkce ChangeMenuAction() a odpovídají položkám menu Save a Save As. Virus používá funkci AssignMakroToFile() pro uskutečnění propojení mezi soubor SAM a SMM. Funkce FindFirst() a FindNext() jsou virem použity k vyhledávání dalších potenciálních cílů v podobě souborů SAM. Viry pro AmiPro mají nižší šanci se šířit pomocí e-mailů než makro viry pro Microsoft Office.

3.7.30 Viry pro Corel Script Produkty Corel Draw podporují skriptovací jazyk, který je uložen v souborech s příponou CSC. (Novější verze programu Corel Draw rovněž podporují VBA.) Viry Corel Scriptu typicky vyhledávají své oběti pomoci funkce FindFirstFolder().Virus CSC/CSV identifikuje už jednou infikované oběti ověřováním výskytu značky "REM ViRUS" v souborech CSC. Pokud virus CSV nenalezne uvnitř souboru tuto značku, pokusí se jej infikovat přiložením vlastního skriptu na začátek souboru pomocí příkazů print #. Poté pokračuje ve vyhledávání pomocí funkce FindNextFolder(). V praxi to funguje tak, že virus vytvoří nový skript hostitele se stejným jménem, zkopíruje se do něj a poté do souboru doplní původní kód hostitele.

REM ViRUS GaLaDRieL FOR COREL SKRIPT bY zAxOn/DDT

Virus CSC/PVT funguje na základě podobné strategie. Pomocí stejné funkce hledá další soubory k infekci. Před pokusem o infekci vyhledává v souborech značku REM PVT, která může být umístěna kdekoliv ve skriptu, přičemž jejíž přítomnost indikuje, že soubor je již infikován.

REM PVT by Duke/SMF

Narozdíl od viru CSV se virus PVT pokouší připojovat na konec skriptů. Důsledkem toho je fakt, že originální skript je spuštěn jako první, a teprve po jeho ukončení je spuštěn příslušný virový kód.

Počítačové viry – analýza útoku a obrana

99

3.7.31 Závislost na makrech produktů Lotus 1-2-3 Ačkoliv existují informace o hromadném rozšíření makro viru pro produkty Lotus 1-2-3 pod jménem Ramble, aktuální hrozba dokonce ani není virová. Namísto toho se jedná o dávkový virus. (Tím ovšem nechci říci, že makra produktů Lotus 1-2-3 nejsou schopny infikovat dokumenty Lotus 1-2-3.)

Virus BAT/Ramble vytvořený autorem skrývajícím se pod pseudonymem "Q The Misanthrope" funguje tímto způsobem: uživatel neprve musí otevřít "trojanizovaný" dokument Lotusu 1-2-3. Škodlivé makro produktu Lotus se po otevření souboru aktivuje a je vloženo do sešitu na rozsah A8167 ... A8191.

Tímto způsobem není pro uživatele viditelné. Po spuštění makra je vytvořen dávkový virus v souboru C:\WINSTART.BAT. Po vytvoření dávkového viru je původní škodlivý kód z dokumentu odstraněn pomocí příkazu /RE (Range Erase). Je také odstraněno jméno makra, které se automaticky zobrazovalo při otevření dokumentu.

Je zde potřeba zmínit skutečnost, že novější verze produktů Lotus 1-2-3 mají odlišný formát dokumentu, který povoluje konverzi starších verzí maker.

3.7.32 Závislost na instalačních skriptech systému Windows 32bitové verze Windows s sebou přinesly soubory INF. Tyto skripty jsou spouštěny přes rozhraní Windows Setup API. Instalační skripty mají různé sekce pro instalaci a odinstalaci. Skript může být vytvořen ručně nebo za použití programů jako BATCH.EXE nebo generátorů souborů INF od Microsoftu.

Jednou z mnoha funkcí instalačních skriptů je využití souboru autoexec.bat. Do tohoto automaticky spouštěného dávkového souboru mohou být přímo vkládány příkazy při instalaci nebo odinstalaci nějakého programu. Toho je dosaženo pomocí příkazu UpdateAutoBat instalační sekce, která je spojena se jménem sekce skriptu. Tato sekce obsahuje příkazy umožňující mazání řádků – a podobně i přidávání nových škodlivých příkazů – za pomoci CmdDelete a CmdAdd. (Příkaz CmdDelete bývá také používán pro vymazání škodlivého kódu v případě, že byl vložen do souboru při předchozím útoku.)

Autor viru pod jménem 1nternal vytvořil celou skupinu virů, mezi nimiž je například rodina INF/Vxer, která využívá infekce souborů INF pomocí dávkového zpracování. Položky CmdAdd jsou zde použity k přesunu virového kódu do souboru AUTOEXEC.BAT. Díky tomu pak virus při každém startu systému prohledává složku Windows\INF na účelem nalezení dalších INF souborů vhodných pro infekci.

3.7.33 Závislost na AUTORUN.INF a souborech INI systému Windows Soubory AUTORUN.INF a soubory INI jsou svojí strukturou velmi podobné instalačním skriptům Windows. Některé viry modifikují soubor AUTORUN.INF tak, aby byly automaticky spouštěny kdykoliv, když je načten vyměnitelný disk.

AUTORUN.INF je novou vlastností systémů Windows 95 firmy Microsoft. Původně byl navržen pro spouštění aplikací pokaždé, když uživatel vložil CD disk do jednotky CD-ROM. Pokud soubor AUTORUN.INF existuje v kořenovém adresáři vyměnitelného disku, je obsah tohoto disku, na většině 32bitových systémů Windows, spuštěn automaticky. Novější verze systému Windows tuto funkčnost primárně podporují pouze pro CD-ROM mechaniky.

100

Kapitola 3 – Prostředí škodlivého kódu

Existuje celá řada položek registru, které jsou spojeny s funkčností funkce Autorun. Pokud je taková volba zapnuta, je AUTORUN.INF interpretován, přičemž je použita jeho sekce Autorun. Sekce Autorun podporuje příkaz Open, který může být použit pro spuštění a vykonání programů. Tímto příkazem tak může být škodlivý kód spuštěn zcela automaticky.

Pro vypnutí této funkčnosti pro všechny disky je potřeba modifikovat položku registru HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer a nastavit položky NoDriveAutoRun nebo NoDriveTypeAutoRun na nějakou upravenou hodnotu jako třeba 0xFF. Soubory Windows INI jsou cílem útoků z podobných důvodů. Například soubor WIN.INI podporuje sekce Windows. V této sekci existuje položka run=, která může být použita pro spuštění aplikace během startu Windows. Různé trojské koně tuto položku často modifikují, aby dosáhly svého spuštění při startu operačního systému.

3.7.34 Závislost na HTML (Hypertext Markup Language) HTML ve své striktní formě nepodporuje běh škodlivého kódu, podporuje však skripty jako například VBScript nebo JScript. Díky tomu pak mohou některé viry útočit i přímo na soubory HTML. Jedním z nejúspěšnějších škodlivých programů je červ W32/Nimda, který byl objeven v září 2001.

Nimda útočí na HTML soubory vkládáním malých částí JSkriptu. Tyto kousky kódu otevírají EML soubor, který obsahuje upravený MIME exploit. Kód JScriptu používá k otevření EML souboru funkci pro otevírání oken. Výsledkem toho je, že soubor s červem je automaticky spuštěn poté, co uživatel vstoupí na webovou stránku obsahující kompromitovaný HTML kód a současně používá zranitelnou verzi prohlížeče Internet Explorer.

Některé HTML hrozby jsou z HTML stránek spuštěny pomocí odkazu HREF. Stránky oklamou uživatele a donutí ho spustit takto odkazovaný škodlivý kód.

První pokusy o HTML viry jsou připisovány autorovi jménem 1nternal. Přestože byly zpočátku považovány za HTML viry, správnější je jejich individuální zařazení, které je založeno na konkrétním použitém skriptovacím jazyku, jako je například VBS nebo JavaScript.

3.8 Závislost na zranitelnosti Rychle se šířící červi jako například W32/CodeRed, Linux/Slapper, W32/Blaster nebo Solaris/Sadmind mají jednu podobnou vlastnost a to takovou, že se mohou šířit pouze tehdy, pokud je možné konkrétní systém exploitovat pomocí známého zranitelného místa. Pokud systém zranitelný není, nebo již byl záplatován, nemůže být červem napaden. Je však známá existence červů používajících celou řadu exploitů, typickým příkladem je W32/Welchia. Takže je možné, že po záplatování konkrétních zranitelností, bude systém dále napadnutelný jinými způsoby.

Této problematice se podrobněji věnuje kapitola 10.

Počítačové viry – analýza útoku a obrana

101

3.9 Závislost na času a datu Tyrell: Tak v čem je problém?

Roy: Smrt!

Tyrell: Smrt. Aha, tak to se obávám, že se neobracíte na správnou osobu.

Roy: Chci prodloužit život...

– Blade Runner, 1982 Některé viry se šíří pouze v daném konkrétním časovém rozmezí. Jiné viry se zase odmítají šířit před nebo po konkrétním datu. Příkladem může být například červ W32/Welchia, který činí pokusy o infekci souborů pouze do ledna 2004.

Dalším příkladem může být třeba původní červ W32/CodeRed, obsahující rutiny, které ukončují jeho fungování v roce 2001. Později byly ovšem uvedeny modifikované varianty červa neobsahující tuto rutinu, což viru zajišťovalo "věčný život". Řízení životních cyklů probíráme podrobněji v kapitole 10.

3.10 JIT závislost – viry Microsoft .NET Přirozený vývoj ambiciózního počítačového jazyka od společnosti Microsoft vyústil ve vývojové prostředí .NET Framework a Just-in-Time kompilaci. Spustitelné soubory prostředí .NET jsou docela podobné PE (portable executable) souborům. Takový soubor obsahuje minimum kódu, který je závislý na použité architektuře44. Zkompilovaný PE soubor v sobě obsahuje jazyk MSIL (Microsoft Intermediate Language) a informace o metadatech. První viry napadající soubory .NET ještě nebyly závislé na JIT. Například virus Donut45 vytvořený autorem Benny v únoru roku 2002. Tento virus napadal soubory prostředí .NET v místě jejich nativního přístupu, a to záměnou funkce importu _CorExeMain() (ve skutečnosti rovněž používající inicializaci JIT) za vlastní kód viru a následným připojením se na konec souboru. O několik měsíců později se už objevily viry závislé na JIT, které byly schopny infikovat vykonatelné soubory MSIL. První takový vir má na svědomí Gigabyte.

W32/HLLP.Sharpei40 implementoval jednoduchou infekční metodu vkládající kód na začátek souboru.

MSIL kód viru je kompilován pomocí CLR (common language runtime) prostředí .NET Frameworku.

JIT nekompiluje modul při svém spuštění, ale pouze poté, co je spuštěna speciální funkce. Teprve pak je MSIL kód přeložen pro použitou architekturu, přičemž se začne vykonávat nativní kód. Obrázek 3.11 ukazuje zprávu – payload viru W32/HLLP.Sharpei.

Obrázek 3.11 Payload zpráva viru Sharpei.

102

Kapitola 3 – Prostředí škodlivého kódu

V roce 2004 se objevila další technika útoku na .NET soubory. Tyto nové viry paraziticky infikují programy MSIL. Protože jsou na vytvoření mnohem složitější, logicky se nemohly objevit dříve. Někteří výzkumníci dokonce vůbec neočekávali, že by se takto komplexní MSIL techniky vůbec kdy objevily.

Například metamorfní virus MSIL/Gastropod používá jmenný prostor System.Reflection.Emit ke znovuvytvoření svého kódu, přičemž hostitelský program pozměňuje až po vytvoření svého virového těla.

Gastropod je výtvorem autora jménem Whale, který také vytvořil virus W95/Perenast. (Tvůrce Whale byl v roce 2004 dopaden ruskou policí. Byl donucen zaplatit pokutu ve výši zhruba $50.)

Jiným případem je virus MSIL/Impanate, který používá jak 32bitové, tak i 64bitové soubory MSIL, které infikuje pomocí techniky vstupních bodů, EPO (Entry Point Obscuring), a to bez použití jakékoliv kódu knihoven. Autorství MSIL/Impanate je připisován tvůrci vystupujícím jako "roy g biv".

Poznámka Více informací o infekčních technikách naleznete v kapitole 4. Metamorfní viry pak probíráme v kapitole 7.

3.11 Závislost na archivovaných formátech Některé viry nedisponují schopností infikovat zkomprimované soubory. Několik málo virů infikuje pouze je. Většina virů tak napadá klasické binární soubory, společně se soubory ZIP, ARJ, RAR a CAB (abychom jmenovali ty nejběžnější).

Metoda šíření viru skrytého v achivovaném souboru získala na popularitě ihned poté, co Microsoft doprogramoval pro program Outlook funkci chránící před viry. Outlook od této chvíle nespouští běžně spustitelné soubory, přičemž nejnovější verze se dokonce chovají tak, že takové soubory jsou běžnému uživateli zcela skryty. Autoři virů nicméně rychle zjistili, že mají možnost posílat zkomprimované soubory, které nejsou Outlookem odstraňovány.

Někteří červi rozesílající e-maily nebo červi hromadně rozesílající e-maily, jako například W32/Beagle@mm46 používají přílohy chráněné heslem. Protože heslo a informace o tom, jak heslo použít, jsou uživateli dostupné, může být uživatel škodlivým kódem přesvědčen ke spuštění příslušné aplikace, jakou je například WinZip, a pomocí hesla soubory následně rozbalit a spustit. Takové viry mají často k dispozici vlastní komprimační knihovny, čímž tak mohou vytvářet další zkomprimované soubory Souboroví infektoři obvykle vkládají nový soubor do zkomprimovaného souboru. Taková infekce souborů ZIP je usnadněna tím, že ZIP pro každý soubor v archivu ukládá hlavičku adresáře. Nalezením této hlavičky může virus vkládat nové soubory do archivu a snažit se donutit uživatele pomocí různých triků ke spuštění. Virus například může vložit soubor s názvem "readme.com" a jednoduše doufat, že bude uživatelem spuštěn, aby si mohl přečíst "dokumentaci".

Některé velmi komplexní viry, mezi něž se řadí například ruský Zhengxi47, infikují i samo-rozbalitelné EXE soubory, přičemž mají schopnost infikovat více souborových archivů, včetně zkomprimovaného formátu HA, který je uvnitř těchto binárních souborů.

Počítačové viry – analýza útoku a obrana

103

3.12 Závislost na příponě souboru Některé viry je možno považovat za závislé na příponě souboru. V závislosti na příponě může být soubor umístěn do odlišných prostředí pro jejich vykonání. Jedním z příkladů může být záměna přípon COM a BAT (ASCII). COM soubor pak může fungovat jako binární, zatímco v případě BAT vypadá jako dávkový ASCII soubor Další běžné závislosti následují: 

COM/VBS



COM/OLE2 (jednoduchá varianta má hlavičku souboru OLE2)



HTA/SKRIPT



MHTML (binární+skript)



INF/COM



PIF/mIRC/BATCH

Tato metoda je často používána k oklamání antivirových skenerů ohledně toho, jaký typ objektu právě zkoumají. Protože skenery často používají hlavičku a příponu souboru ke zjištění prostředí souboru, mohou být jejich schopnosti (jako například heuristika) ovlivněny špatnou identifikací objektu.

Například PIF červi typicky používají kombinaci mIRC, BAT nebo dokonce VBS, která je přímo založena na závislosti na příponě. Soubor s koncovkou PIF bude zpracován jako PIF. Soubor příponou BAT se ovšem namísto toho spustí jako dávkový soubor, přičemž sekce PIF umístěná na začátku bude jednoduše ignorována. Dalšími příklady jsou triky s mIRC a dávkovým soubory. Obrázek 3.12 ukazuje strukturu souboru PIF připravenou pro záměnu přípony. Tuto techniku používá například virus Phager.

Obrázek 3.12

Struktura souboru PIF, která je závislá na koncovce.

Dalším zástupcem této techniky je virus INF/Zox, infikující soubory INF systému Windows. Hlavní tělo viru INF/Zox je umístěno v INF souboru nazvaným jako ULTRAS.INF. Tento INF soubor je po přejmenování schopen fungovat jako COM soubor.

Virus ve formě INF používá příkaz CmdAdd k útoku na soubor AUTOEXEC.BAT. Dále používá příkaz CopyFile sekce DefaultInstall pro zkopírování souboru ULTRAS.INF jako Z0X.SYS. Kouzlo spočívá v tom, že nová sekce AUTOEXEC.BAT přejmenuje soubor Z0X.SYS na Z0X.COM a spustí jej. Virus začíná komentářem ve formě INF použitím středníku (;) (0x3b).

104

Kapitola 3 – Prostředí škodlivého kódu

Pokud je soubor nahrán jako DOSový soubor COM, značka je ignorována jako instrukce porovnání (CMP) . Po komentáři následuje binární kód, který se "přeloží" do instrukce skoku (JMP) na binární pozici viru na konci souboru: 13BE:0100 3B00

CMP

AX,[BX+SI]

; Instrukce porovnání je ignorována

13BE:0102 E9F001

JMP

02F5

; Skok na začátek binárního viru.

Zox je virus přímé akce pracující pomocí přepisování. Soubory INF přepisuje svým kódem.

3.13 Závislost na síťovém protokolu Nejčastější cíl útoků v současnosti představuje Internet. Protokoly TCP a UDP jsou mobilním škodlivým kódem48 používány k útokům na nové cíle. Existují však i starší červi, jako třeba Father Christmas, kteří se na Internetu šířit nemohou, protože se spoléhají pouze na protokoly DECNET. Na síťových protokolech jsou tak typicky závislí především červi.

3.14 Závislost na zdrojových kódech Některé šikovné počítačové viry, jako například rodina W32/Subit, umí infikovat zdrojové soubory, jakými jsou například zdrojáky programu Visual Basic nebo Visual Basic .NET. Další viry se mohou šířit uvnitř zdrojových souborů C nebo Pascal. Tyto hrozby jsou poměrně novou záležitostí.

Prozkoumejte si výpis zdrojového souboru v C v jeho čisté a poté infikované podobě.

Výpis 3.2 Virus infikující zdrojové kódy. #include <stdio.h> void main(void) { printf("Hello World!"); }

Infikovaná kopie bude vypadat takto: #include <stdio.h> void infect(void) { /* kód viru hledající soubory *.c k infikování */ } void main(void) { infect(); /* Neodstraňujte tuto funkci!! */ printf("Hello World!"); }

Počítačové viry – analýza útoku a obrana

105

Po spuštění infikované kopie a jejím následném zkompilování, se virus pokusí vyhledat další zdrojové kódy a infikovat je. Tyto viry obvykle používají svůj vlastní kód ve formě dlouhého řetězce. Rodina virů W32/Subit používá sloučené řetězce pro definici svého kódu, počínaje následujícími řádky: J = "44696D20532041732053797374656D2E494F2E53747265616D5772697465720D" J = J & "0A44696D204F2C205020417320446174650D0A44696D2052204173204D696372" J = J & "6F736F66742E57696E33322E52656769737472794B65790D0A52203D204D6963"

Toto je pak pomocí Visual Basic .NET převedeno na tento kód: Dim S As System.IO.StreamWriter Dim O, P As Date Dim R As Microsoft.Win32.RegistryKey : :

Tento zdrojový kód virus replikuje ve dvou fázích. První fází je běh už infikované aplikace s vloženým kódem viru. Poté, co je infikovaným programem vyvolána funkce New(), začne kód viru hledat další zdrojové soubory Visual Basic .NET a kopírovat do nich svůj zdrojový kód. Ve druhé fázi virus Subit vloží volání funkce pro běh samotného virového těla. Výsledkem je to, že po kompilaci a spuštění kompromitovaného zdrojového souboru se může virus dále šířit.

Hlavním problémem těchto virů je to, že se mohou vyskytovat kdekoliv v aplikaci. Mohou být vloženy do libovolného místa toku kódu. Kód viru bude proto přeložen různě – v závislosti na jazyce, verzi kompilátoru a různých nastaveních, což vede k tomu, že na různých systémech bude virus v binární podobě vypadat odlišně.

3.14.1 Zdrojové kódy trojských koní Samotná idea výhradně "zdrojových virů" pochází z úžasné myšlenky "samo-reprodukujících se programů" od Kena Thomsona (spoluautora operačního systému UNIX). Ve svém článku "Reflection on Trusting Trust,"49 představuje Thomson myšlenku programů v C, nazývaných jako "guines", které na výstupu zobrazují přesnou kopii svého zdrojového kódu. Nápad je to milý a jednoduchý. Zdrojový kód programu je definován jako řetězec, který je na pak výstup posílán pomocí funkce printf().

Thomson rovněž uvedl myšlenku hacku CC (kompilátoru jazyka C), jejíž hlavní pointou je modifikace zdrojového kódu CC tak, aby při každém použití binárního kódu kompilátoru došlo k následujícím věcem: 

Rozpoznal se okamžik, kdy je kompilován zdrojový kód programu určeného pro přihlašování (loginu), přičemž je do jeho zdrojového kódu vložen trojský kůň. Tyto programy obsahující trojské koně pak ponechávají uživateli možnost se přihlásit pomocí svých údajů. Přihlašovací programy jsou pak schopny pustit útočníka, který zadává patřičné heslo, k jakémukoliv účtu.



Byla provedena modifikace zdrojových kódů CC za běhu. Takto je možnost modifikovat zdrojový kód dostupná pouze během kompilace, přičemž je po kompilaci rychle odstraněna.

106

Kapitola 3 – Prostředí škodlivého kódu

Infektory zdrojového kódu používají Thompsonovy principy pro injektování sebe sama do zdrojových kódů aplikací. Podobné viry se budou objevovat stále častěji, s rostoucí popularitou open-source kódu.

3.15 Závislosti na zdrojích v platformách Mac a Palm Některé viry jsou závislé na systémových zdrojích. Například prostředí systému Macintosh je platformou bohatou na zdroje (resources). Nejrůznější funkce jsou implementovány ve formě zdrojů, které mohou být snadno editovány přes editory zdrojů (resource editors). Například zde existuje zdroj definující menu. Takové definice jsou vyvolávány v závislosti na menu. Mac tyto informace ukládá ve dvou větvích – větvi datové a větvi zdrojové. Zdroje uložené ve zdrojové větvi obsahují kód. Protože i datové soubory mohou obsahovat kód, není zde rozdíl mezi datovými a zdrojovými soubory tak ostrý jako u PC. Viry používající MDEF (definice menu) na Apple Macintosh používají techniku, kdy nahrazují definici menu sebou samotnými. Ke spuštění viru tak dojde při každé aktivaci daného menu.

Tabulka 3.3 obsahuje běžné typy zdrojů na Apple Macintosh. Je to nekompletní seznam nejčastějších zdrojů, které jsou cílem útoků na platformě Macintosh36.

Tabulka 3.3 – Běžné typy Mac zdrojů.

Typ zdroje

Popis

ADBS

Služba Apple Desktop

CDEF

Funkce definice řízení

DRVR

Ovladač zařízení

FMTR

Kód formátu disku

CODE

Segment kódu

INIT

Zdroj inicializace kódu

WDEF

Funkce definice oken

FKEY

Funkce počtu definic

PTCH

Rutina záplatování ROM

MMAP

Funkce myši

Podobné závislosti jsou patrné i u virů pro Palmy. V prostředí Palm jsou spustitelné soubory aplikací uloženy v souborech PRC se speciálními zdroji. Po spuštění aplikace jsou odsud vyvolány. Do jisté míry jsou pak zdroje DATA a CODE důležité pro spouštění programu. Virus Palm/Phage, objevený v září 2000, načítá vlastní zdroje DATA a CODE a přepisuje jimi zdroje ostatních aplikací. Závislost na zdrojích je velmi podobná závislosti uvedené v případě Macintoshů.

Počítačové viry – analýza útoku a obrana

107

3.16 Závislost na velikosti hostitele Aby mohla být infekce nějaké aplikace provedena přesně, má mnoho počítačových virů nastavený maximální nebo minimální limit velikosti souborů, které ještě budou infikovat. Například – takové soubory COM není možné spustit v prostředí DOSu, pokud jsou větší než segment kódu. Proto většina DOSových virů obsahuje limity zabraňující infekci souborů, u kterých by jejich velikost – po přidání viru – vzrostla nad akceptovatelnou mez.

V jiných případěch, jako je příklad viru W95/Zmist, se používá omezení na horní hranici, například 400 kB na soubor. To zvyšuje spolehlivost infekce snížením rizik, která se objevují v případě infekce příliš velkých souborů. Závislost na velikosti hostitele může být základem tzv. "antigoat" techniky (viz kapitola 6), která zabraňuje infekci některých testovacích souborů používaných antivirovými výzkumníky.

3.17 Závislost na debbuggerech Některé viry využívají nainstalovaný debugger, obvykle DOSovský DEBUG.EXE, pro převedení sebe sama z textové do binární podoby nebo k tvorbě binárních souborů. Podobné hrozby většinou používají zavedený debug skript jako: DEBUG <debugs.txt

Vstupní soubor pak obsahuje příkazy pro DEBUG, jako: N example.com E 100 c3 RCX 1 W Q

Tento skript vytvoří 1 bajt dlouhý COM soubor obsahující jedinou instrukci RET. Samotná instrukce RET v COM souboru je nejkratším možným programem COM. COM soubory jsou nahrávány na offset 0x100 programového segmentu. Před programovým segmentem je umístěn PSP (prefix programového segmentu), na offsetu 0, a proto samotná instrukce RET předá ovládání vrcholku PSP, přičemž předpokládá, že je zásobník prázdný – je předána nula. Trik spočívá ve faktu, že vrcholek PSP obsahuje 0xCD, 0x20 (INT 20 – návrat do DOSovského přerušení): 13BA:0000 CD20

INT

20

Takže, pokud vykonávání programu skončí na offsetu 0, program bude jednoduše ukončen.

Poznámka Příkaz N je používán k nastavení jména výstupu. Příkaz E je používán k vkládání dat do paměťového offsetu. Registr CX drží nižší část 16bitového slova délky paměti a BX horní. Příkaz W se používá k zápisu obsahu do souboru. A nakonec – příkaz Q ukončí debugger. Viry typicky za použití mnoha řádku dat použijí příkaz Enter pro vytvoření škodlivého programu v paměti.

108

Kapitola 3 – Prostředí škodlivého kódu

Autor virů Vecna použil tento postup u rodiny W95/Fabi na vytváření EXE souborů společně s použitím maker MS Wordu. Z infikovaného dokumentu MS Office virus Fabi vytvoří v kořenovém adresáři nový soubor pojmenovaný jako FABI.DRV, přičemž za použití příkazu PRINT do něj vloží debug skript: OPEN "C:\FABI.DRV" FOR OUTPUT AS 1 PRINT #1, "N C:\FABI.EX" PRINT #1, "E 0100 4D 5A 50 00 02 00 00 00 04 00 0F 00 FF FF 00 00" PRINT #1, "E 0110 B8 00 00 00 00 00 00 00 40 00 1A 00 00 00 00 00"

Obsah FABI.DRV bude vypadat takto: N C:\FABI.EX E 0100 4D 5A 50 00 02 00 00 00 04 00 0F 00 FF FF 00 00 ; DOS EXE header E 0110 B8 00 00 00 00 00 00 00 40 00 1A 00 00 00 00 00 [Tělo viru je oříznuto odsud] E 4D20 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F E 4D30 10 0F 10 0F 10 0F 10 FF FF FF RCX 4C3A W Q

Zároveň je podobným způsobem vytvořen další dávkový soubor. Ten obsahuje příkaz, který ke skriptu nasměruje program DEBUG: DEBUG <C:\FABI.DRV>NUL

Povšimněte si, že program DEBUG neumí vytvářet EXE soubory. Přinejmenším je neumí ukládat z paměti do tvaru EXE. Snadno však umí uložit obsah paměti jako soubor bez přípony. Právě virus Fabi používá takový přístup. Nejprve uloží soubor pomocí programu DEBUG jako FABI.EX a poté pomocí dalšího dávkového souboru se soubor FABI.EX přejmenuje na FABI.EXE. Je evidentní, že pokud program DEBUG.EXE není na systému nainstalován, nebo se jmenuje jinak, některé viry nebudou částečně fungovat, popř. nebudou fungovat vůbec.

3.17.1 Zamýšlené hrozby spoléhající na debugger Některý škodlivý kód může pro replikaci vyžadovat, aby uživatel trasoval kód v debuggeru. Za některých okolností je to možné v případě určitých makro hrozeb. Pokud v průběhu spouštění makra dojde k chybě, Microsoft Word může uživateli nabídnout – jako možnost vedoucí k vyřešení problému – spuštění debuggeru makra. Pokud se uživatel rozhodne debugger spustit, a podaří se mu vypátrat, v čem vlastně vězí problém, může tímto způsobem chybu obejít. Výsledkem je to, že se virus může v tomto omezeném a speciálním prostředí šířit. Mezi antivirovými výzkumníky však panuje shoda o tom, že se jedná pouze o zamýšlené hrozby.

Počítačové viry – analýza útoku a obrana

109

3.18 Závislost na kompilátoru a linkeru Různé binární hrozby během své replikace rozšiřují i svůj vlastní zdrojový kód. Tato technika je často vídána u červů v případech, kdy není zaručena binární kompatibilita. Například Linux/Slapper přenáší svůj zdrojový kód pro rozšíření své schopnosti replikovat se mezi různými druhy Linuxu. Nejdříve se pomocí exploitace dostane do systému, pomocí příkazu gcc zkompiluje svůj kód a nalinkuje se do binárního souboru. Červ zakóduje svůj zdrojový kód na systému útočníka a zkopíruje jej do cílového systému, kde jej uloží v dočasné složce jako skrytý soubor. Poté je soubor dekódován pomocí příkazu uudecode: /usr/bin/uudecode -o /tmp/.bugtraq.c /tmp/.uubugtraq;

Zdrojový kód je pak zkompilován následujícím příkazem: gcc -o /tmp/.bugtraq /tmp/.bugtraq.c –lcrypto;

Virus ke správné kompilaci potřebuje knihovnu crypto, takže kromě gcc musí být na počítači nainstalovány patřičné knihovny programu crypto. V jiném případě červ nebude schopen správné provádět svoji infekční strategii, ačkoliv může být schopen se dostat do dalších systémů exploitací slabiny Open SSL. Výhodou infekce založené na zdrojových kódech je zvýšená kompatibilita ohledně verze operačního systému. Nicméně existuje i řada nevýhod. Je například dobrým zvykem neinstalovat kompilátory do standardních míst na disku, což snižuje riziko úspěšného napadení takovými viry. Mnoho systémových administrátorů toto ovšem zanedbává.

3.19 Závislost na vrstvě překladači zařízení Mnoho článků, které doposud vyšly, se shoduje na faktu, že pro prostředí Windows CE nikdy nebudou implementovány viry a skutečně – po mnoho let jsme na takový výtvor nenarazili. Nicméně v červenci 2004 autor vystupující pod jménem Ratter představil první virus, WinCE/Duts.1520, který útočí právě na tuto platformu, jak je vidět na obrázku 3.13.

Obrázek 3.13

Zpráva viru WinCE/Duts na HP iPAQ H2200.

Na mnoha současných zařízeních PDA pracuje virus WinCE/Duts úspěšně, protože procesor ARM je dostupný v celé řadě kapesních počítačů, jako například na zařízení HP iPAQ H2200 (a mnoha dalších

110

Kapitola 3 – Prostředí škodlivého kódu

z řady iPAQ), Sprint PCS Toshiba 2032SP, T-Mobile Pocket PC 2003, Toshiba e405, Viewsonic V36 atd.

Na základě Pocket PC jsou navíc uváděna mnohá GSM zařízení.

Je zajímavostí, že WinCE/Duts.1520 je schopen infekce na mnoha systémech navzdory faktu, že virus vypadá, jako by byl vytvořen pouze pro konkrétní verzi Windows CE. Například virus používá ordinální importovací mechanismus, což se může jevit jako silné omezení. Autor se domníval, že WinCE/Duts je kompatibilní pouze s Windows CE 4. V našich testech však virus fungoval i na Windows CE 3.

Je překvapivé, jak dlouho Windows CE odolávaly virům. Windows CE bylo totiž vytvořeno pro různé procesory, což je zdrojem nekompatibility (nehomogenní prostředí), která poněkud limituje případnou úspěšnost virů pro tento operační systém. Navíc programy Pocket Word a Pocket Excel, které jsou k dispozici ve všech verzích Windows CE, nepodporují makra. V budoucnu se ovšem možná dočkáme nepříjemných překvapení.

Před příchodem Windows CE 3.0 byla jak tvorba, tak i distribuce programů pro Windows CE složitá kvůli binární kompatibilitě. Kompilované soubory byly vyvíjeny jako přenositelné spustitelné soubory (PE), nicméně program fungoval pouze na procesoru, pro který byl zkompilován. To bylo velmi náročné jak pro vývojáře, tak i pro uživatele (který se nemohl dočkat nových programů).

Závislost na CPU je totiž natvrdo vložena do hlavičky PE souborů. Například u procesoru SH3 bude hlavička PE souborů obsahovat typ stroje 0x01A2, přičemž sekce kódu bude obsahovat pouze kód kompatibilní s touto architekturou.

Kompatibilní aplikace pro platformu SH3 se tak tvoří snadno – nicméně Windows CE byly vytvořeny tak, aby mohly podporovat větší množství procesorů, jako například SH3, SH4, MIPS, ARM a podobně.

Důsledkem toho se nemohou nativní viry pro Windows CE šířit na různých procesorech. Například již zmiňovaný virus WinCE/Duts.1520 neinfikuje systémy běžící na procesorech SH3.

Autoři virů také mohou vytvořit Win32 virus, který do systému Windows CE virus vloží pomocí programu Microsoft ActiveSync. Podobný virus pak může snadno posílat e-maily a šířit svou verzi pro Intel, ale opět bude schopen infikovat pouze určité typy procesorů. V budoucnu tento problém bude mizet s přibývajícími kompatibilními zařízeními. Například – nové procesory XScale jsou zpětně kompatibilní s procesory ARM. A procesory XScale se neobjevují pouze v zařízeních Pocket PC, ale i Palm.

Zjevně se tak útočníkům otevírají možnosti tvorby "multi-platformních" virů – jak pro Palm, tak i pro Pocket PC. Microsoft pro usnadnění práce vývojářů začal podporovat nový formát spustitelných souborů (CEF, common executable file). CEF jsou zkompilovány pomocí nástrojů Windows CE jako eMbedded Visual C++ 3.0. CEF je vlastně speciální druh souboru PE. CEF je nezávislý na procesoru a dovoluje tvorbu přenositelných aplikací pro Windows CE. CEF podporují kód MSIL. V nástrojích eMbedded Visual C++ (kompilátorech, linkerech a SDK) je vývojářům formát CEF k dispozici podobně jako jiné zařízení (například MIPS nebo ARM). Při kompilaci CEF aplikace linker a kompiler udělají vše potřebné, přičemž vytvoří kód nezávislý na použitém procesoru. Výstupem jsou stále DLL nebo EXE soubory, nicméně ty obsahují pouze instrukce nezávisející na použitém hardware.

Formát CEF umožňuje Windows CE vývojářům podporovat všechny CPU architektury Windows CE 3.0 a vyšších. Protože je CEF pomocným jazykem, výrobci procesorů snadno mohou přidávat nové typy

Počítačové viry – analýza útoku a obrana

111

procesorů podporující aplikace CEF. Například zařízení HP Jornada 540 je vybaveno zabudovanou vrstvou překladače zařízení. Soubor CEF může mít pri distribuci příponu EXE, takže z perspektivy uživatele se nic nezmění.

Překladač zařízení je závislý na verzi procesoru a verzi Windows CE. Překladač zařízení překládá CEF do kódu nativního pro procesor v okamžiku, když se vykonatelný soubor CEF instaluje do zařízení.

To se odehrává plynule, aniž by si toho uživatel mohl všimnout, a to i přes fakt, že předtím, než se po kliknutí soubor spustí, vzniká drobná prodleva. Operační systém zachytí jakýkoliv pokus o nahrání a spuštění souborů CEF EXE, DLL a OCX a automaticky zavolá překladač.

Například – pokud je zařízení Pocket PC postaveno na procesoru SH3, vrstva překladače se pokusí soubor zkompilovat do formátu SH3. Aktuální soubor CEF bude nahrazen zkompilovanou verzí nativní pro SH3; původní soubor je tak zcela nahrazen. A rovněž první spuštění MSIL a JIT (Just-in-Time), na Pocket PC, přepíše soubory v systému.

Autoři virů v budoucnu výhod formátu CEF určitě využijí. 32bitový Windows virus může snadno nainstalovat CEF verzi schopnou šíření na všech zařízeních Pocket PC, protože tato verze bude operačním systémem přeložena do nativní formy. A my můžeme jen doufat, že formát CEF nebude podporovat žádný jiný systém mimo zařízení Windows CE. Protože jsou spustitelné soubory zkonvertovány do nového formátu za běhu, změní se obsah příslušných souborů. To je ještě větší problém, než konverze maker v produktech Microsoft Office50. Toto bude v budoucnu novým zdrojem starostí pro antivirové výzkumníky, programy ověřující kontrolu integrity, a také pro systémy blokující přístup podle chování.

Pro antivirové programy je především problematické detekovat a identifikovat kód viru ve všech možných nativních verzích, stejně jako v původní MSIL formě. Pokud je MSIL virus spuštěn na stroji předtím, nežli ho antivirový program zná, bude úspěšně spuštěn a jeho kód bude převeden do libovolného formátu v závislosti na systému. MSIL signatura viru už poté nebude antivirovému programu užitečná.

Virus proto musí být detekován ve všech možných překladech, což vůbec není jednoduchý úkol.

Stejně tak se ovšem jedná o problém pro programy ověřující integritu, protože obsah programu se změní nejenom v paměti, ale také na disku. Proto nejsme schopni programem pro kontrolu integrity získat jistotu, zdali se jedná o výsledek virové infekce nebo o pouhý překlad nativního kódu. A aby toho nebylo málo, systémy blokující přístup podle chování (behaviors blockers systems) mají rovněž problém s obsahem měnícím se na disku – tuto činnost totiž mohou snadno považovat za aktivitu viru.

3.20 Závislost na vkládaných objektech První známý virus schopný infekce dokumentů MS Wordu 6 se pod jménem Anarchy.609351 se objevil v roce 1997. Nepřekvapí nás fakt, že o dalších podobných virech jsme už dlouho neslyšeli, protože útok na dokumenty tohoto typu vyžaduje přidávání maker, což není triviální úkol. Anarchy byl DOSovský infektor souborů typu COM, EXE a DOC. První virus infikující dokumenty VBA z binárního kódu pocházel z Ruska. Virus jménem {Win32,W97M} /Beast.41472.Ase začal šířit v dubnu roku 1999. Virus je napsán v Borland Delphi a zkompilován do 32bitového formátu PE.

112

Kapitola 3 – Prostředí škodlivého kódu

Virus Beast pro infekci dokumentů používá odlišný způsob než většina binárních virů. Místo obvyklého způsobu útoku na VBA formát, tedy bajt po bajtu, autor viru Beast použil knihovny OLE (Object Linking and Embedding), jako například AddOLEObject(), pro injektování kódu makra a vloženého vykonatelného kódu do dokumentů pomocí interní OLE podpory programu Microsoft Word. Pomocí OLE podpory je virus schopen injektovat vložený (a spustitelný) kód do dokumentů VBA. Tento vložený objekt není za použití obvyklých způsobů viditelný uživateli. To je zajištěno trikem, kterým virus schovává ikonu vloženého objektu.

Virus hledá aktivní otevřené dokumenty programu Word. Pokud je ukazatel na aktivní dokument dostupný, virus zavolá svůj infekční modul. Nejdříve se pokusí zjistit, zdali už v dokumentu nejsou nějaké vložené objekty – tato rutina ovšem často nepracuje správně, což vede k tomu, že dokumenty jsou v mnoha případech infikovány vícenásobně.

Virus Beast se dále pokusí vložit ve formě C:\I.EXE do dokumentu pojmenovaného jako 3BEPb (rusky zvíře). Pokud tato procedura proběhne tak, jak je plánováno, nové makro pojmenované jako AutoOpen() bude úspěšně injektováno do dokumentu.

Vykonání vloženého objektu je zajištěno použitím metody Activate na formu 3BEPb v aktivním dokumentu: ActiveDocument.Shapes("3BEPb").Activate

S virem Beast se tak objevila nutnost detekovat a odstraňovat vložené škodlivé objekty v dokumentech, což není příliš jednoduchý problém k řešení.

3.21 Závislost na vlastním prostředí Jedna zajímavá závislost se objevuje v případě, kdy je škodlivý kód umístěn ve svém vlastním prostředí na dané platformě. Rodina virů W32/Franvir představuje dobrý příklad tohoto konceptu.

Virus Franvir je zjevně Win32 aplikací. Do podoby 32bitového PE programu je zkompilován pomocí Borland Delphi. Skutečná binární podoba viru ovšem využívá knihovnu Game Maker vytvořenou Holanďanem Markem Overmarsem (http://www.cs.uu.nl/people/markov/gmaker/doc.html).

Virus Franvir byl vytvořen francouzským autorem virů za pomoci skriptovacího jazyka Game Maker, nazývaného jako GML (Game Maker Language). Ten je přístupný registrovaným uživatelům programu Game Maker, který nabízí vývojářům celou řadu bezpečnostních nastavení pro použití různých funkcí.

Tato nastavení jsou programátorovi plně k dispozici, a proto může autor škodlivého software snadno zneužít jazyk GML programu Game Maker pro vytváření virů.

Program Game Maker slouží jako profesionální prostředí pro vývoj her. Profesionálové v něm už vytvořili stovky skvělých her. Může být použit ke tvorbě všech typů her, včetně stříleček, hlavolamů a dokonce 3D her. Příkladem hry vytvořené v tomto prostředí může být třeba hra Doomed (viz obrázek 3.14).

Počítačové viry – analýza útoku a obrana

Obrázek 3.14

113

Doomed v akci.

GML poskytuje funkce pro práci s registry, soubory a vykonávání programů. Operace pro práci se soubory nabízejí extrémně velké možnosti a nabízejí vývojářům her velkou flexibilitu pro instalování a spouštění programů – tohle všechno ovšem může být použito autory škodlivého software. Některé funkce GML obsahují následující: file_exists(fname) file_delete(fname) file_copy(fname,newname) file_open_write(fname) directory_create(dname) file_find_first(mask,attr) file_find_next() file_attributes(fname,attr) registry_write_string_ext()

GML skripty jsou uloženy uvnitř programu Game Maker, nicméně je k nim přistupováno a jsou spouštěny samotným prostředím interpreta programu Game Maker. Franvir je zašifrovaný GML skript. Kopíruje se po celém disku pod různými jmény. Dále se instaluje do místních složek P2P (peer-to-peer), vytváří sdílenou složku programu KaZaA, za předpokladu, že chybí ("kazaa\my shared folder\") a mění nastavení programu KaZaA tak, aby tato složka byla sdílena. Dále škodí smazáním souboru win.com v adresáři Windows. Franvir je tak potřeba klasifikovat jako P2P červa Win32. Fakticky je to ale GML skript, který přenáší své vlastní prostředí na další platformy. Pokud se virus úspěšně šíří, může pomocí funkce show_message() zobrazit chybovou hlášku zobrazenou na obrázku 3.15.

Obrázek 3.15

Falešná chybová hláška viru Franvir.

114

Kapitola 3 – Prostředí škodlivého kódu

A ve výjimečných případech může Franvir – podobně jako DOSový virus Playgame – nabídnout hraní nějaké hry namísto provádění škodlivých akci na disku jako svoji aktivační rutinu. Ostatně, co jiného čekat od typického auta viru?

3.22 Multipartitní viry První virus infikující jak COM soubory, tak i boot sektory, pojmenovaný jako Ghostball, objevil Fridrik Skulason v říjnu 1989. Další ukázkou multipartitního viru byl virus Tequila, který uměl infikovat jak DOSovské EXE soubory, tak i MBR (master boot sector) harddisků.

Multipartitní viry jsou nesnadným oříškem z hlediska odstraňování. Například virus Junkie infikuje soubory COM a současně se jedná o boot virus. Junkie umí infikovat soubory COM ve skrytých sekcích (partitions)52 disku, které někteří výrobci HDD používají pro ukrytí různých speciálních dat a kódu označením specifických položek těchto sekcí.

Protože se Junkie nahrává do paměti ještě předtím, než jsou tyto skryté soubory zpřístupňovány, jsou tyto soubory snadno infikovány. Skenery obvykle prohledávají pouze viditelné části disku, takže podobné infekce mohou vést k opakovaným infekcím. To proto, že ačkoliv byl virus odstraněn ze všech míst (kromě ukrytých částí), může virus infikovat systém ihned poté, co se spustí z COM souboru umístěného na skryté části disku.

V minulosti byly boot a multipartitní viry obzvláště úspěšné v infekcích systémů s operačním systémem DOS. Na moderních systémech Windows jsou už výrazně menší hrozbou, ačkoliv doposud existují.

Virus Memorial53 byl jedním z prvních virů, který byl schopen infikovat jak DOSovské COM soubory, tak i soubory typu EXE a PE. Payload viru Memorial je zobrazen na obrázku 3.16.

Obrázek 3.16

Zpráva viru W95/Memorial.

W95/Memorial rovněž používal formát VxD (Virtual Device Driver) systému Windows 9x pro nahrání se do režimu jádra, přičemž infikoval soubory vždy, když k nim bylo přistoupeno. Důsledkem toho virus Memorial infikuje jak 16bitové, tak i 32bitové soubory.

Dalším zajímavým příkladem multipartitní infekce je ruský virus 3APA3A, který byl objeven v Moskvě v říjnu 199454. 3APA3A je normální boot virus, který zabírá na disketě 2 sektory, a který používá unikátní infekční metodu. Infikuje totiž jádro DOSu – soubor IO.SYS. Nejprve vytvoří kopii IO.SYS, a poté přepíše originál. Po infekci pak kořenový adresář obsahuje dva soubory IO.SYS, přičemž první je

Počítačové viry – analýza útoku a obrana

115

nastaven jako jméno svazku (volume label) na disku, takže příkaz DIR neukáže dva soubory, ale jméno svazku "IO SYS" a jednotlivý soubor IO.SYS. Pointa je v tom, donutit DOS, aby spustil infikovanou kopii souboru IO.SYS. Po svém vykonání virus následně spustí původní soubor. K infekci dojte díky tomu, že DOS načte první infikovaný soubor IO.SYS, bez ohledu na atributy. Tato metoda reprezentuje speciální podtřídu doprovodných (companion) infekčních technik.

3.23 Závěr Nová virová prostředí se objevují každý rok. Za posledních 20 let jsme byli svědky toho, jak byly naprogramovány počítačové viry snad pro všechna možná prostředí. Tisíce lidí po celém světě tvořilo a stále tvoří počítačové viry. Díky tomu stojíme uprostřed mlýnských kamenů rozšiřujících se bezpečnostních problémů se škodlivým kódem, přičemž pozitivní výsledky výzkumu počítačových virů jsou závislé na skutečně seriózní vědecké práci. O tom, že nás počítačové viry budou doprovázet i v dalších dekádách, není vůbec žádných pochybností. Úvodní výzkum Freda Cohena o počítačových virech z roku 1984 prosazoval myšlenku, že problém počítačových virů je jednoznačně problémem integrity. Během posledních 20ti let se tato myšlenka výrazně rozšířila z integrity souborů na integritu aplikací a programů operačního systému. Moderní počítačové viry jako W32/CodeRed a W32/Slammer jasně ukazují, kudy se bude další vývoj ubírat – počítačové viry nebude možné vyhledávat ověřováním integrity souborů, protože takové viry se budou rozšiřovat z jednoho systému na druhý pomocí sítě, přičemž budou injektovat nové procesy v adresovacích prostorech, a jako takové nebudou vůbec uloženy na disku.

Problém počítačových virů měnících vlastní prostředí k obrazu svému je jedním z mnoha úskalí, která nás čekají. Například virus W32/Perrun se připojuje k souborům JPEG. Tyto soubory obvykle nejsou infekční (pokud prohlížeč obrázků nemá nějakou seriózní zranitelnost, viz například Microsoft Security Bulletin MS04-02855). Perrun však modifikuje prostředí infikovaného hosta vložením komponenty extraktoru, což vede k tomu, že JPEGy kompromitované Perrunem nejsou na čistém systému infekční, nicméně na již jednou infikovaném systému ano. Podobné počítačové viry tudíž mohou modifikovat prostředí takovými způsoby, že nelze zaručit platnost prakticky žádného z dřívějších předpokladů.

Odkazy 1. Dr. Vesselin Bontchev, "Methodology of Computer Anti-Virus Research", University of Hamburg, Dissertation, 1998.

2. Dr. Harold Highland, "A Makro Virus", Computers & Security, srpen 1989, str. 178-188.

3. Joe Wells, "Brief History of Computer Viruses", 1996, http://www.research.ibm.com/antivirus/timeline.htm.

4. Dr. Peter Lammer, "Jonah's Journey," Virus Bulletin, listopad 1990, str. 20.

5. Peter Ferrie, osobní komunikace, 2004.

6. Jim Bates, "WHALEC9A Dinosaur Heading For Extinction", Virus Bulletin, listopad 1990, str.

17-19.

116

Kapitola 3 – Prostředí škodlivého kódu

7. Eric Chien, "Malicious Threats to Personal Digital Assistants", Symantec, 2000.

8. Dr. Alan Solomon, "A Brief History of Viruses", EICAR, 1994, str. 117-129.

9. Intel Pentium Processor III Specification Update, http://www.intel.com/design/PentiumIII/specupdt/24445349.pdf.

10. Mikko Hypponen, soukromá komunikace, 1996.

11. Thomas Lipp, "Computerviren", 64'er, Markt&Technik, březen 1989.

12. Peter Szor, "Stream of Consciousness," Virus Bulletin, říjen 2000, str. 6.

13. Peter Szor and Peter Ferrie, "64-bit Rugrats", Virus Bulletin, červenec 2004, str. 4-6.

14. Marious Van Oers, "Linux Viruses – ELF File Format", Virus Bulletin Conference, 2000, str. 381400.

15. Jakub Kaminski, "Not So Quiet on the Linux Front: Linux Malware II", Virus Bulletin Conference, 2001, str. 147-172.

16. Eugene Kaspersky, "Shifter.983", http://www.viruslist.com, 1993.

17. Sarah Gordon, "What a (Winword.) Concept," Virus Bulletin, září 1995, str. 8-9.

18. Sarah Gordon, "Excel Yourself!" Virus Bulletin, srpen 1996, str. 9-10.

19. Yoshihiro Yasuda, osobní komunikace, 2004.

20. Dr. Igor Muttik, "Makro Viruses – Part 1", Virus Bulletin, září 1999, str. 13-14.

21. Dr. Vesselin Bontchev, "The Pros and Cons of WordBasic Virus Up-conversion", Virus Bulletin Conference, 1998, str. 153-172.

22. Dr. Vesselin Bontchev, "Possible Makro Virus Attacks and How to Prevent Them", Virus Bulletin Conference, 1996, str. 97-127.

23. Dr. Vesselin Bontchev, "Solving the VBA Up-conversion Problem", Virus Bulletin Conference, 2001, str. 273-300.

24. Nick FitzGerald, "If the CAP Fits", Virus Bulletin, září 1999, str. 6-7.

25. Jimmy Kuo, "Free Anti-Virus Tips and Techniques: Common Sense to Protect Yourself from Makro Viruses", NAI White Paper, 2000.

26. Dr. Vesselin Bontchev, osobní komunikace, 2004.

27. Jakub Kaminski, "Disappearing Makros – Natural Devolution of Up-converted Makro Viruses", Virus Bulletin Conference, 1998, str. 139-151.

28. Katrin Tocheva, "Multiple Infections", Virus Bulletin, 1999, str. 301-314.

29. Dr. Richard Ford, "Richard's Problem", osobní komunikace v VMAKRO mailing listu, 1997.

30. Dr. Vesselin Bontchev, "Makro Virus Identification Problems", Virus Bulletin Conference, 1997, str. 157-196.

31. Dr. Vesselin Bontchev, soukromá komunikace, 1998.

Počítačové viry – analýza útoku a obrana

117

32. Vesselin Bontchev, "No Peace on the Excel Front", Virus Bulletin, duben 1998, str. 16-17.

33. Gabor Szappanos, "XML Heaven", Virus Bulletin, únor 2003, str. 8-9.

34. Peter G. Capek, David M. Chess, Alan Fedeli, and Dr. Steve R. White, "Merry Christmas: An Early Network červ", IEEE Security & Privacy, http://www.počítač.org/security/v1n5/ j5cap.htm.

35. Dr. Klaus Brunnstein, "Computer 'Beastware': Trojan Horses, Viruses, worms–A Survey", HISEC'93, 1993.

36. David Ferbrache, "A Pathology of Computer Viruses," Springer-Verlag, 1992, ISBN: 3-54019610-2.

37. Peter Szor, "Warped Logic?" Virus Bulletin, červen 2001, str. 5-6.

38. Mikhail Pavlyushchik, "Virus Mapping", Virus Bulletin, září 2003, str. 4-5.

39. Eugene Kaspersky, "Don't Press F1", Virus Bulletin, leden 2000, str. 7-8.

40. Peter Szor, "Sharpei Behaviour", Virus Bulletin, duben 2002, str. 4-5.

41. Gabor Kiss, "SWF/LFM-926 – Flash in the Pan?" Virus Bulletin, únor 2002, str. 6.

42. Dmitry Gryaznov, soukromá komunikace, 2004.

43. Sami Rautiainen, soukromá komunikace, 2004.

44. Philip Hannay and Richard Wang, "MSIL for the .NET Framework: The Next Battleground?", Virus Bulletin Conference, 2001, str. 173-196.

45. Peter Szor, "Tasting Donut", Virus Bulletin, březen 2002, str. 6-8.

46. Peter Ferrie, "The Beagle Has Landed", http://www.virusbtn.com/resources/viruses/ indepth/beagle.xml.

47. Eugene Kaspersky, "Zhengxi: Saucerful of Secrets", Virus Bulletin, duben 1996, str. 8-10.

48. Roger A. Grimes, Malicious Mobile Code, O'Reilly, 2001, ISBN: 1-56592-682-X. 49. Ken Thomson, "Reflections on Trusting Trust", Communication of the ACM, Vol. 27, No. 8, August 1984, str. 761-763, http://cm.bell-labs.com/who/ken/trust.html.

50. Peter Szor, "Pocket Monsters", Virus Bulletin, srpen 2001, str. 8-9.

51. Igor Daniloff, "Anarchy in the USSR", Virus Bulletin, říjen 1997, str. 6-8.

52. Lakub Kaminski, "Hidden Partitions vs. Multipartite Viruses–I'll be back!", Virus Bulletin Conference, 1996.

53. Peter Szor, "Junkie Memorial", Virus Bulletin, září 1997, str. 6-8.

54. Dr. Igor Muttik, "3apa3a", http://www.f-secure.com/v-descs/3apa3a.shtml, 1994.

55. "Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution", MS04-028, http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx.

118

Kapitola 3 – Prostředí škodlivého kódu

KAPITOLA 4 Klasifikace metod infekce

„Veškeré umění je imitací přírody."

– Seneca

120

Kapitola 4 – Klasifikace metod infekce

V této kapitole se dozvíte o běžných technikách infekce počítačových virů, které se zaměřují na různé formáty souborů a systémové oblasti.

4.1 Boot viry První známé úspěšné počítačové viry napadaly tzv. boot sektory disků. V roce 1986 vytvořili na IBM PC dva pakistánští bratři první takový virus pojmenovaný jako Brain.

V dnešní době se technika infekce boot sektoru téměř nepoužívá. S bootovacími viry byste se nicméně měli seznámit, protože dovedou infikovat počítače bez ohledu na operační systém, který je na nich nainstalovaný.

Boot viry zneužívají procesu startování osobních počítačů typu PC. Protože většina počítačů neobsahuje operační systém v paměti ROM (Read-Only Memory, paměť pouze pro čtení), potřebují nahrát systém odněkud odjinud – například z disku nebo z lokální počítačové sítě.

Typický disk IBM PC je organizován do čtyř oblastí (tzv. partitions), které mají na některých operačních systémech, jako je třeba MS-DOS a Windows NT, přiřazená jednotlivá písmena abecedy, většinou C:, D: atd. Písmena disků jsou specifikem jednotlivých operačních systémů – například UNIXové systémy místo nich používají tzv. přípojné body (mount points). Většina počítačů používá pouze dvě oblasti, které jsou být uživatelům zpřístupněny. Někteří dodavatelé počítačů, jako například COMPAQ a IBM, často používají skryté diskové oblasti k uložení dodatečných nástrojů BIOSu. Skryté oblasti nemají přiřazeno žádné písmeno abecedy, čímž je přístup k nim více ztížen. Dobré nástroje, jako třeba Norton Disk Editor, ale umí takové oblasti na disku odhalit (diskové nástroje používejte velmi opatrně – můžete si s nimi nechtěně poškodit vaše data!).

Počítače typu PC obvykle načítají OS z pevného disku. U dřívějších systémů ovšem nebylo pořadí zavádění definováno, a proto se počítač pokusil vždy bootovat z disketové mechaniky, což vytvářelo vhodné prostředí pro aktivaci počítačových virů ještě před startem samotného operačního systému. ROM-BIOS tedy přečte první sektor zaváděcích disků dle jejich pořadí specifikovaného v BIOSu a v případě úspěchu jej uloží do paměti na adresu 0:0x7C00 a spustí1.

Na novějších systémech je každá disková oblast rozdělena na další oblasti. Disk se vždy adresuje přes hlavu, stopu a sektor. Master Boot Record (MBR) je vždy umístěn na hlavě 0, stopě 0, sektoru 1, což je první sektor na pevném disku. MBR obsahuje generický kód určený pro konkrétní procesor, který vybere aktivní bootovací oblast z tabulky rozdělení disku (tzv. partition table, PT), která se nachází v datové oblasti MBR. Na začátku MBR je krátký kód, kterému se říká zavaděč (boot strap loader).

Každá položka v PT obsahuje: 

Adresu prvního a posledního sektoru oblasti.



Příznak, zda-li je oblast bootovatelná.



Typ oblasti.



Offset prvního sektoru oblasti od začátku disku v sektorech.



Velikost oblasti v sektorech.

Počítačové viry – analýza útoku a obrana

121

Zavaděč najde aktivní oblast a nahraje její první logický sektor jako boot sektor, který obsahuje kód specifický pro konkrétní operační systém, narozdíl od MBR, který je určen pro obecné použití nezávisle na OS. Takto IBM PC jednoduše podporují více oblastí s různými souborovými a operačními systémy, nicméně tím rovněž usnadňují práci počítačovým virům. Kód z MBR je možné jednoduše nahradit virovým kódem, který použije originální MBR poté, co nahraje sám sebe a dále zůstává v paměti (v závislosti na nainstalovaném operačním systému). V případě MS-DOSu mohou boot viry zůstat v paměti a infikovat za běhu další média. Pár šikovných boot virů, jako například Exebug, vždy donutí počítač, aby je nahrál do paměti a pak dokončí bootovací proces. Exebug mění nastavení BIOSu v paměti CMOS takovým způsobem, aby zmátl počítač a on předpokládal, že systém neobsahuje žádnou disketovou mechaniku – počítač tedy prvně nabootuje z MBR a jakmile je virus aktivován, zjistí, zdali je disku A: disketa. Pokud ano, pak nahraje boot sektor z diskety a předá mu řízení. Pokud se pokusíte nabootovat z diskety, virus se vás pokusí oklamat, abyste si mysleli, že jste z ní skutečně nabootovali, ačkoliv se tak nestalo.

V případě disket je boot sektor prvním sektorem, ve kterém je uvedeno, jaké soubory operačního systému se mají nahrát, jako například IBMBIO.COM a IBMDOS.COM. Proto se doporučuje nastavit proces bootování tak, aby se prvně bootovalo z pevného disku. V prvních generacích IBM PC nebyl takto bootovací proces navržen, takže pokud byla disketa v jednotce A:, počítač se pokusil nabootovat z ní. Boot viry využívají právě tuto chybu v návrhu, která se dá omezit správným nastavením bootovacího procesu.

Poznámka Pokud máte v počítači připojený SCSI disk, systém nemusí být schopen z něj nabootovat, protože k těmto diskům není možné přistupovat přímo z BIOSu.

Následující části podrobně rozebírají druhy technik infekce MBR a boot sektorů.

4.1.1 Techniky infekce Master Boot Recordu (MBR) Infekce MBR je pro viry relativně jednoduchou úlohou. Velikost MBR je 512 bajtů, takže se do něj vejde jen malý kousek kódu, ale pro malé viry je to stále více než dost místa. Obvykle se MBR infikuje okamžitě po nabootování z infikované diskety z jednotky A:.

4.1.1.1 Infekce MBR nahrazením zavaděče Klasický druh MBR virů používá k přístupu k diskům pro čtení a zápis službu BIOSu INT 13h. Většina MBR infektorů nahrazuje zavaděč umístěný na začátku disku svojí vlastní kopií a nezasahují do tabulky rozdělení disku. To je velmi důležité, protože když se bootuje z diskety, je pevný disk přístupný pouze tehdy, pokud je tabulka rozdělení disku svém na místě. V opačném případě pak nemá DOS žádnou možnost najít data na disku.

Virus Stoned je typickým představitelem používání této techniky. Virus uloží původní MBR na sektor 7 (viz obrázek 4.1). Jakmile se virus aktivuje díky nahrazení MBR, přečte původní uložený MBR ze sekto-

122

Kapitola 4 – Klasifikace metod infekce

ru 7 do paměti a předá mu řízení. Těsně za MBR bývá většinou k dispozici pár prázdných sektorů a právě toho využívá virus Stoned. Na tuto výchozí podmínku se nicméně nedá stoprocentně spolehnout a to je přesně ten případ, kdy MBR viry po infekci znemožní korektní nabootování systému.

Obrázek 4.1

Typické rozmístění disku před a po infekci virem Stoned.

4.1.1.2 Nahrazení MBR kódu bez jeho uložení Další virovou technikou k infekci MBR je ponechání tabulky rozdělení a přepsání zavaděče bez jeho úschovy. Takové viry potřebují zachovat funkčnost původního MBR – musí najít aktivní diskovou oblast, nahrát ji a posléze ji předat řízení.

Jedním z prvních virů, který začal používat tuto techniku, byl virus Azusa2, který byl objeven v lednu 1991 v kanadském Ontariu. Takové viry nemohou být odstraněny běžnými metodami, protože není nikde zachována původní kopie MBR. Antivirové programy rychle zareagovaly na toto nebezpečí přidáním standardního MBR kódu do svých produktů. Napadený počítač se pak vyléčil přepsáním virového kódu tímto kódem.

Počítačové viry – analýza útoku a obrana

123

4.1.1.3 Infekce MBR změnou záznamu v tabulce rozdělení disku Snadným cílem MBR infektorů je tabulka rozdělení disku. Změnou záznamu v této tabulce virus zajistí nahrání původního boot sektoru. MBR tedy nahraje zavirovaný boot sektor místo původního, přičemž původní boot sektor je nahrán virem ihned po jeho aktivaci. Virus StarShip je představitelem takové techniky. Některé viry, jako například někteří členové rodiny Ginger, mění záznamy v tabulce rozdělení disku tak, že dojde k zacyklení oblasti3,4, což v případě MS-DOSu verze 4.0 až 7.0 způsobí, že počítač po nabootování skončí v nekonečné smyčce. Ke správnému nabootování z diskety je pak zapotřebí MS-DOS verze 3.3x nebo DOS systém jiný než od Microsoftu, jako například PC DOS.

4.1.1.4 Uložení MBR na konec pevného disku Běžnou metodou infekce MBR je kompletní nahrazení MBR a uložení původní kopie na konec pevného disku, v naději, že jej nic nepřepíše. Některé opatrnější viry ještě zmenší velikost diskové oblasti a zabrání tím přepsání původního MBR. Tuto techniku například používá multipartivní (multipartite) virus Tequila.

4.1.2 Techniky infekce DOS BOOT Recordu (DBR) Boot sektorové viry infikují první sektor disket, a případně i boot sektory pevných disků. Technik infekce boot sektoru je více než technik infekce MBR.

4.1.2.1 Standardní technika infekce boot sektoru Jednou z nejpoužívanějších technik infekce boot sektoru vynalezly viry typu Stoned. Stoned infikuje boot sektor diskety nahrazením 512-bajtového boot sektoru svojí kopií a uložením původní kopie boot sektoru na konec kořenového adresáře.

V praxi je tato technika bezpečná jen do té doby, dokud není na disketě příliš mnoho souborů. Pak vede spuštění příkazu DIR k vypsání smetí na obrazovce.

4.1.2.2 Boot viry, které formátují dodatečné sektory Některé boot viry jsou příliš velké na to, aby se vešly do jednoho sektoru. Většina disket se dá ovšem naformátovat tak, že se na ně vejde více dat, než je obvyklé při klasickém běžném formátování. Ne všechny disketové mechaniky umožňují formátování dodatečných sektorů, většina však ano. Například disketová mechanika mého prvního klonu IBM PC nepodporovala přístup na takto zformátované diskety.

Výsledkem bylo to, že na mém systému nefungoval některý software s ochranou proti kopírování.

Některé ochrany proti kopírování totiž často využívají možnosti naformátovat na disketě dodatečné sektory umístěné mimo obvyklý rozsah. Proto obyčejné nástroje na kopírování disket, jako třeba DISKCOPY, nedokáží vytvořit identickou kopii dat.

124

Kapitola 4 – Klasifikace metod infekce

Některé viry speciálně naformátují několik sektorů na disketě, aby znemožnily antivirovým programům přístup k původní kopii boot sektoru. Hlavním důvodem používání této techniky je nicméně hlavně to, že virus je příliš velký.

Indonéský virus Denzuko je představitelem této techniky. Denzuko byl vypuštěn během jara roku 1988 a narozdíl od jiných virů je znám jeho autor – napsal jej Denny Yanuar Ramdhani. Přezdívka autora byla Denny Zuko, která pochází ze jména "Danny Zuko", což byl hlavní hrdina oblíbeného filmového muzikálu Pomáda, kterého hrát John Travolta5. Tento boot virus byl mezi prvními, který začal útočit na jiné počítačové viry. Denzuko odstraňoval virus Brain, pokud jej našel v počítači.

Denzuko se také uměl projevovat (rutinám starajícím se o cílený projev viru říkáme payload) – po stisku kláves Ctrl-Alt-Del na zlomek sekundy zobrazil tento obrázek a poté provedl restart počítače, přičemž nadále zůstal v paměti6.

Obrázek 4.2

Payload viru Denzuko.

Tuto techniku používá také velmi složitý a nebezpečný maďarský stealth BOOT/MBR virus Töltögetö (známý též jako Filler). Vytvořil jej jeden student výpočetní techniky na střední škole v Székesfehérváru v Maďarsku v roce 1991. Filler formátuje diskety o kapacitě 360 kB a 1.2 MB – konkrétně sektory na stopě 40 nebo 80. Tyto oblasti disket obvykle nebývají naformátované.

Výhodou tohoto druhu techniky infekce je možnost oživení mrtvého virového kódu. První oživovací pokusy byly u virů objeveny na počátku 90. let. Například některé COM infektory se pokoušely umístit sama sebe k těsnému konci disku mimo obvykle formátované oblasti a pak předaly řízení nahranému sektoru. Většina prvních antivirových řešení při procesu léčení nepřepisovala celý virový kód, zejména ne ten kód, který byl umístěn na disku mimo obvyklý rozsah. Antivirové programy opravily pouze boot sektor, přičemž odstřihnutý virový kód byl považován za mrtvý. Ovšem, někteří autoři virů toho využili a mrtvý kód viru oživili prostřednictvím jiného viru.

4.1.2.3 Boot viry, které označují sektory za vadné Zajímavou metodou některých boot virů je nahrazení původního boot sektoru virovým kódem a uložení původní kopie nebo další části viru do prázdného clusteru, který se poté ve FAT tabulce označil jako vadný. Představitelem této virové techniky je nebezpečný Disk Killer, který byl vytvořen v dubnu v roce 19897.

Počítačové viry – analýza útoku a obrana

125

4.1.2.4 Boot viry, které neukládají původní boot sektor Některé boot viry vůbec neukládají původní boot sektor diskety a místo toho napadají aktivní boot sektor nebo MBR pevného disku, aby pak předaly řízení uloženým boot sektorům na pevném disku.

Infekce na disketě tak nemůže být opravena standardními technikami, neboť virus nepotřebuje ukládat původní boot sektor. Protože je boot sektor specifický pro konkrétní operační systém, není proces léčení tak jednoduchý, jako v případě nahrazení MBR kódu – pro jednotlivé OS totiž existuje mnoho odlišných boot sektorů OS. Většina antivirových řešení řeší tento problém tak, že přepíší virový kód kódem standardního boot sektoru, který zobrazí výzvu uživateli, zda-li se má nabootovat z pevného disku.

Výsledkem je, že se disketa nedá uvést stoprocentně do původního stavu.

Druhou, méně obvyklou metodou je přepsání boot sektoru diskety virovým kódem, který napadne MBR nebo boot sektor pevného disku. Virus potom zobrazí falešnou hlášku, něco ve stylu "Non-system disk or disk error" a nechá uživatele načíst virus z pevného disku. Tuto techniku například využívá virus Strike.

Další metodou infekce boot sektoru disket bez uložení originálu je předstírání funkčnosti boot sektoru a načtení některých systémových souborů, což ovšem funguje pouze za předpokladu, že se virus strefí do správného operačního systému. Takhle to například dělá virus Lucifer.

4.1.2.5 Boot viry, které ukládají původní boot sektor na konec disku Další kategorie boot virů nahrazuje původní boot sektor přepsáním virovým kódem a uložení jeho kopie na konec pevného disku. Slavným představitelem této techniky je virus Form, který ukládá originální boot sektor na těsný konec disku. Form předpokládá, že se tento sektor téměř vůbec nepoužívá, a může tak sloužit jako vhodné místo na uložení kopie s nízkým rizikem pozdějšího přepsání. Virus tedy nepotřebuje nijak označovat tento sektor, a ani měnit velikost diskové oblasti.

Jiné boot viry také ukládají boot sektor na konec aktivní diskové oblasti a navíc zmenšují její velikost tak, že sektor s původní kopií se nebude pro systém tvářit jako volný – nedojde tedy k jeho nechtěnému přemazání. Eventuálně je možné ze stejného důvodu pozměnit datovou oblast boot sektoru.

4.1.3 Boot viry, které dovedou pracovat s Windows 95 Několik boot virů, obvykle multipartitního charakteru, útočí na ovladač disketové mechaniky, který je uložený v \SYSTEM\IOSUBSYS\HSFLOP.PDR. Tato technika se prvně objevila ve slovinské rodině virů nazvané jako Hare (nebo také Krishna) v květnu roku 1996, kterou napsal Demon Emperor.

Viry odstraňují tento soubor z toho důvodu, aby získaly přístup k obsluze služby BIOSu INT 13h, pokud systém obsahuje aktivní Windows 95. Bez tohoto triku by totiž boot viry nemohly infikovat diskety prostřednictvím volání INT 13h, protože by pro ně nebylo toto volání dostupné.

4.1.4 Možné útoky boot virů v síťovém prostředí Bezdiskové pracovní stanice bootují prostřednictvím souboru uloženého na serveru. Například na serverech Novell NetWare existuje příkaz DOSGEN.EXE, který dovede vytvořit obraz bootovací diskety

126

Kapitola 4 – Klasifikace metod infekce

NET$DOS.SYS pro použití na terminálech. Ty mají speciální EPROM čip, který umí na síti najít bootovací image.

To nabízí útočníkovi dvě možnosti. Ta první je infekce nebo nahrazení souboru NET$DOS.SYS na serveru v okamžiku, kdy je k němu umožněn přístup. Druhou možností je simulace funkčnosti serverového kódu a hostování falešných virtuálních serverů prostřednictvím virového kódu umístěného na síti.

Takové viry zatím nejsou známy, nicméně soubor NET$DOS.SYS bývá často infikován a zůstává nepostřehnut mnoha antivirovými skenery.

4.2 Techniky infekce souborů V této části se dozvíte o běžných metodách infekce souborů, které autoři8 virů léta používali k nabourání se do hostitelských systémů.

4.2.1 Přepisující viry Některé viry jednoduše najdou vhodný soubor na disku a přepíší ho vlastní kopií. Jedná se o velmi primitivní techniku, která se však nejsnadněji implementuje. Takové jednoduché viry dovedou napáchat velkou škodu, pokud přepíší soubory na celém disku.

Soubory napadené přepisujícími viry nemohou být vyléčeny a musí být smazány z disku a následně obnoveny ze záloh. Následující obrázek 4.3 ukazuje, jak se změní obsah hostitelského programu po napadení takovým virem.

Obrázek 4.3

Přepisující virus, který mění velikost hostitele.

Přepisující viry nejsou obvykle příliš úspěšné, protože vedlejší efekty jejich činnosti uživatelé rychle objeví. Takové viry mají nicméně větší šířící potenciál, zejména tehdy, pokud se tato technika zkombinuje s technikou šíření po síti. Například virus VBS/LoveLetter.A@mm odesílá sebe sama na jiné systémy prostřednictvím elektronické pošty. Po své aktivaci přepíše svojí kopií všechny soubory s těmito příponami: .vbs, .vbe, .js, .jse, .css, .wsh, .sct, .hta, .jpg, .jpeg, .wav, .txt, .gif, .doc, .htm, .html, .xls, .ini, .bat, .com, .avi, .qt, .mpg, .mpeg, .cpp, .c, .h, .swd, .psd, .wri, .mp3 a .mp2.

Počítačové viry – analýza útoku a obrana

127

Jinou metodou infekce přepisem používají takzvané "mrňavé" (tiny) viry. Typickou rodinou tohoto typu infektorů je rodina Trivial pro operační systém DOS. Během počátku 90. let se mnoho autorů počítačových virů pokoušelo napsat co nejmenší možný virus. Není tedy překvapením, že existuje mnoho variant viru Trivial. Některé z nich jsou dlouhé pouhých 22 bajtů (Trivial.22).

Algoritmus takových virů je velmi jednoduchý: 1. Vyhledat libovolný soubor (*.*) v aktuálním adresáři.

2. Otevřít soubor pro zápis.

3. Zapsat tělo viru na začátek hostitelského souboru.

Tyto nejkratší viry často nedovedou infikovat více než jeden soubor v aktuálním adresáři – z toho důvodu, že kód na vyhledání dalšího hostitelského souboru by zabral o pár bajtů víc. Takové viry nejsou dostatečně vyvinuty na to, aby byly schopny infikovat soubory určené pouze pro čtení – opět proto, že by to vyžadovalo pár instrukcí navíc.

Virový kód bývá často optimalizován tak, aby využíval nastavení registrů dle konkrétního operačního systému – virus tedy nemusí inicializovat registry, jejichž obsah je předem známý. Díky tomu mohou autoři ještě více zkrátit délku svých virů.

Takové optimalizace mohou nicméně způsobit fatální chyby, pokud se virus spustí na platformě, která registry inicializuje na jiné hodnoty, než jaké virus očekával.

Některé šikovné přepisující viry také používají služeb BIOSu pro zápis sektorů místo DOSových souborových funkcí. Nejprimitivnější forma takového viru byla implementována na 15 bajtů. Virus přepíše každý sektor na disku sebe samým. Poškození systému, ke kterému dojde, je tak závažné, že svou aktivitou velmi záhy zlikviduje hostitelský systém.

Obrázek 4.4 názorně ukazuje přepisující virus, který jednoduše přepíše svým tělem začátek hostitele, přičemž nijak nezmění jeho velikost.

Obrázek 4.4

Přepisující virus, který nemění velikost hostitelského programu.

Kapitola 4 – Klasifikace metod infekce

128

4.2.2 Náhodně přepisující viry Další neobvyklá varianta přepisovací techniky nemění kód programu na jeho začátku – místo toho si náhodně vybere oblast uprostřed souboru, na kterou se zapíše. Virový kód se nemusí za každou cenu aktivovat během spouštění hostitele, ten je ale každopádně nenávratně poškozen a může havarovat už před samotnou aktivací viru. Příkladem takového viru je Omud9, zobrazený na obrázku 4.5.

Obrázek 4.5

Náhodně přepisující virus.

Pro vylepšení výkonu omezením I/O operací jsou moderní antivirové programy optimalizovány tak, aby byly schopny nalézt viry na známých místech. Náhodně přepisující viry jsou problémem pro skenery, protože ty pak potřebují zanalyzovat kompletní obsah hostitele, což je časově a výkonově náročné.

4.2.3 Připojující viry Typickou technikou infekce DOSových COM souborů je vložení instrukce skoku (JMP) na začátek hostitele, která směřuje přesně na jeho konec. Příkladem může být virus Vienna, jehož lehce upravená varianta byla publikována v knize o počítačových virech Ralfa Burgera společně se zdrojovými kódy v letech 1986-87.

Tato technika má své pojmenování podle umístění virového těla, které se připojí na konec hostitele.

Je zajímavé, že některé viry infikují EXE soubory tak, že je nejprve převedou na COM. Tuto techniku například používá rodina viru Vacsina.

Instrukce skoku je někdy nahrazena instrukcemi se stejnou funkčností, jako například těmito: a.) CALL zacatek_viru b.) PUSH offset zacatek_viru RET

První tři přepsané bajty na začátku hostitelského programu jsou uloženy ve virovém těle. Jakmile dojde ke spuštění infikovaného programu, virus načte hostitele do paměti, instrukce skoku přesměruje vykonávání do těla viru, kde typicky dojde k replikaci vyhledáním dalších vhodných souborů k infekci nebo ke spuštění aktivační rutiny a konečně k obnovení hostitele zkopírováním původních bajtů na začátek programu (offset CS:0x100, což je paměťová adresa, na kterou systém nahrává COM soubory) a skokem

Počítačové viry – analýza útoku a obrana

129

zpět na CS:0x100. Soubory COM se nahrávají na tuto adresu proto, že prefix segmentu programu (program segment prefix, PSP) je umístěn na CS:0 - CS:0xFF. Obrázek 4.6 znázorňuje, jak připojující COM virus infikuje hostitelský program.

Obrázek 4.6

Typický způsob infekce připojujícím virem.

Technika připojení na konec souboru se dá implementovat pro libovolný typ spustitelného souboru, například pro EXE, NE, PE, ELF atd. Takové soubory mají hlavičku, která obsahuje adresu hlavního vstupního bodu, který je většinou nahrazena novým vstupním bodem, kterým je začátek virového kódu, připojeného na konec hostitele. Část 4.3 je věnovaná technikám infekce systému Win32 a demonstruje principy technik infekce moderních souborových formátů. Tyto formáty mají obvykle složité interní struktury a nabízející útočníkům více možností.

4.2.4 Viry připojující se na začátek souboru Tato častá technika infekce je založena na principu vložení virového kódu na začátek hostitele. Takové viry nazýváme jako viry připojující se na začátek hostitele, neboli prependery. Jedná se o jednoduchý, avšak úspěšný způsob infekce, který autoři virů implementovali na různých operačních systémech.

Příkladem takového viru je maďarský virus Polimer.512.A, který na začátek hostitele připojuje svůj 512 bajtů dlouhý kód, a který posune obsah hostitelského souboru tak, aby jej následoval.

Podívejme se na začátek tohoto viru v DOSovém DEBUGu. Polimer je vhodným příkladem, protože začátek viru obsahuje neškodnou datovou oblast se zprávou, která se zobrazí během spuštění infikovaných programů. >DEBUG polimer.com -d 142F:0100

E9 80 00 00 3F 3F 3F 3F-3F 3F 3F 3F 43 4F 4D 00

....????????COM.

130

Kapitola 4 – Klasifikace metod infekce

142F:0110

05 00 00 00 2E 8B 26 68-01 00 00 00 00 00 00 00

......&h........

142F:0120

00 00 00 00 00 00 00 00-41 20 6C 65 27 6A 6F 62

........A le’job

142F:0130

62 20 6B 61 7A 65 74 74-61 20 61 20 50 4F 4C 49

b kazetta a POLI

142F:0140

4D 45 52 20 6B 61 7A 65-74 74 61 20 21 20 20 20

MER kazetta !

142F:0150

56 65 67 79 65 20 65 7A-74 20 21 20 20 20 20 0A

Vegye ezt ! .

Virové tělo se nahraje do paměti na offset 0x100. Kód začíná instrukcí skoku (0xe9), která předá řízení virovému kódu, jenž následuje za datovou oblastí. Protože je Polimer 512 bajtů (0x200) dlouhý, bude offset hostitelského programu v paměti tento: 0x300 (0x100+0x200=0x300). A skutečně, v naší ukázce je infikovaný program Free Memory Query. COM prependery mohou jednoduše spustit hostitelský program tak, že zkopírují původní obsah programu na offset 0x100 a předají mu řízení.

-d300 142F:0300

E9 9E 00 0D 46 72 65 65-20 4D 65 6D 6F 72 79 20

....Free Memory

142F:0310

51 75 65 72 79 20 50 72-6F 67 72 61 6D 2C 20 56

Query Program, V

142F:0320

65 72 73 69 6F 6E 20 34-2E 30 33 0D 0A 53 4D 47

ersion 4.03..SMG

142F:0330

20 53 6F 66 74 77 61 72-65 0D 0A 28 43 29 20 43

Software..(C) C

142F:0340

6F 70 79 72 69 67 68 74-20 31 39 38 36 2C 31 39

opyright 1986,19

142F:0350

38 37 20 53 74 65 76 65-6E 20 4D 2E 20 47 65 6F

87 Steven M. Geo

142F:0360

72 67 69 61 64 65 73 0D-0A 1A 00 00 00 00 00 00

rgiades.........

Obrázek 4.7 demonstruje, jak se prepender vkládá na začátek programu.

Obrázek 4.7

Typický virus, který se připojuje na začátek hostitele.

Prependery bývají obvykle napsány v pokročilých programovacích jazycích, jakým je třeba jazyk C, Pascal nebo Delphi. V závislosti na aktuální struktuře spustitelného souboru nemusí být infekce programu tak triviální, jako v případě COM souborů. Přesně z tohoto důvodu viry na disku vytváří dočasný soubor, který obsahuje původní hostitelský program, přičemž pro jeho spuštění se použije funkce typu system(). Takové viry obvykle předají parametry příkazové řádky původnímu programu a tím zachovají funkčnost aplikace, která by mohla být narušena chybějícími parametry.

Počítačové viry – analýza útoku a obrana

131

4.2.5 Klasické parazitické viry Variantou techniky připojení na začátek souboru je technika známá jako klasická parazitická infekce, znázorněná na obrázku 4.8. Takové viry přepíší začátek hostitele vlastním kódem a uloží jej na jeho úplný konec, obvykle na offset délky viru. První takový virus byl Virdem, napsaný Ralfem Burgerem. Ve skutečnosti je Virdem jedním z prvních příkladů souborových virů, který byl zaznamenán; Burgerova kniha nikdy neobsahovala informace o jiných než souborových virech. Burger rozšířil svůj výtvor na konferenci Chaos Computer Clubu v prosinci roku 1986. Často se po vyléčení takto zavirovaných souborů objeví obvyklé problémy. V mnoha případech se oprava provede tak, že se zkopíruje N bajtů na začátek souboru a soubor se zkrátí o velikost souboru mínus N, kde N je typicky velikost viru (ovšem délka souboru se může měnit). Nejčastější příčinou nekorektního léčení je mnohonásobná infekce, tedy situace, kdy je soubor infikován více než jednou.

Obrázek 4.8

Klasický parazitický virus.

V jiných případech má soubor na svém konci nějaká speciální data, jako například dodatečné informace vložené nějakým antivirovým programem. Například virus Jerusalem používal značku MS-DOSu umístěnou na konci souboru, aby rozeznal soubory, které jsou už infikované. Některé z prvních antivirových programů připojovaly na konec všech COM a EXE programů tento řetězec, aby tak zamezily opětovné infekci Jerusalemem. Ačkoliv to může znít jako dobrý nápad, takové změny souborů mohou dezinfekčním programům způsobit problémy. K tomu může dojít třeba v případě, že takto označený soubor byl už napaden jiným parazitickým virem. Jestliže se pro vyléčení souboru použije výpočet "velikost souboru-N", sáhne opravná rutina třeba o 5 bajtů dál za původním programem. Toto léčení pak bude mít za následek poškození programu, který zhavaruje po každém svém spuštění. Tomuto druhu dezinfekce se říká "rychlokvašená oprava" (half-cooked repair10).

Některé speciální parazitické infektory neukládají začátek hostitele na jeho konec a místo toho používají dočasný soubor k uložení této informace mimo hostitele, někdy se skrytými atributy. Například maďarský DOS virus Qpa tuto techniku používá a ukládá 333 bajtů (velikost viru) do speciálního souboru.

132

Kapitola 4 – Klasifikace metod infekce

Tuto techniku používají také členové nechvalně známé rodiny virů W32/Klez pro uložení celého hostitelského programu v novém souboru.

4.2.6 Dutinové viry Dutinové viry (cavity viruses), znázorněné na obrázku 4.9, obvykle nezvětšují velikost svého hostitele.

Místo toho přepíší určitou oblast souboru, do které se mohou bezpečně vložit. Tyto infektory většinou přepisují oblasti binárních souborů, které obsahují nuly, nicméně mohou přepsat i bloky 0xCC, které často používají kompilátory jazyka C pro zarovnání instrukcí. Jiné viry zase přepisují oblast s mezerami (bajty 0x20).

Prvním virem, který začal používat tuto techniku, byl Lehigh v roce 1987. Lehigh byl vcelku neúspěšný virus, nicméně Ken van Wyk zajistil viru mnoho publicity a vytvořil na Usenetu diskusní skupinu VIRUS-L, aby s ostatními prodiskutoval svoje poznatky.

Obrázek 4.9

Mezerový virus, který sám sebe vkládá do mezery v hostiteli.

Dutinové viry obvykle bývají DOS infektory s pomalým šířením. Například bulharské viry Darth Vader nikdy nepůsobily velké škody, především kvůli faktu, že se jedná o pomalý infektor. Vždy počkal, až se program sám zapíše a teprve pak na něj zaútočil.

Virus W2K/Installer (autoři Benny a Darkman) používá tuto techniku k infekci Win32 PE souborů na Windows 2000 bez zvětšování jejich velikosti.

Speciální druh těchto virů zneužívá relokační sekce PE programů. Relokace spustitelných souborů ve většině případů nejsou zapotřebí a novější linkery dovedou zkompilovat spustitelné PE soubory bez relokačních tabulek, čímž tak zmenšit velikost výsledného programu. Dutinové viry útočící na relokace přepíší relokační sekci (pokud ji v programu naleznou). Jestliže je relokační sekce menší než virový kód, virus velikost souboru nezvětší, protože soubor jednoduše nenapadne. Takové viry si pečlivě ověřují, jestli je relokační sekce dostatečně velká nebo zdali je alespoň poslední v pořadí, jinak by došlo k poškození souboru. Tuto techniku například používají rodiny virů W32/CTX a W95/Vulcano.

Počítačové viry – analýza útoku a obrana

133

4.2.7 Dělené dutinové viry Několik virů pro Windows 95 používá dutinovou techniku infekce extrémně úspěšným způsobem, příkladem může být například virus W95/CIH. Jeho virový kód je rozdělený na zaváděcí rutinu a N sekcí.

Zaváděcí rutina (hlavička) viru nejprve nalezne zbylé části virového kódu a načte je do spojité paměti (s pomocí tabulky offsetů, která je uložena v hlavičce). Při infikování virus nejprve najde dostatek prázdných míst v PE souboru a do nich pak nakopíruje jednotlivé části kódu.

Nový vstupní virový bod bude zaznamenán v hlavičce souboru a bude ukazovat na začátek virového kódu, který je obvykle umístěný někde uprostřed hlavičky hostitele. Některé kratší dutinové infektory, jako je třeba Murkry, používají tuto oblast k infekci souborů v jednom kroku. CIH je nicméně delší a potřebuje svůj kód rozdělit do menších částí. Virus spustí hostitelský program skokem na původní uložený vstupní bod. Výhodou této techniky je to, že si virus potřebuje zapamatovat pouze původní vstupní bod hostitele. V načteném programu pak pouze stačí skočit na tu správnou adresu.

Obrázek 4.10 znázorňuje stav hostitelského programu před a po infekci děleným dutinovým virem.

Hostitel by normálně začal na svém vstupním bodu, který je definovaný v hlavičce. Virus nahradí tento bod virovým vstupním bodem, který ukazuje na začátek zavaděče, který poté načte zbývající části kódu.

V případě, že v souboru není dostatek místa pro uložení celého zavaděče do jedné části kódu, infekce neproběhne.

V moderních souborových formátech, jakým je třeba PE, bývají mezery k dispozici a dají se jednoduše najít s použitím informací uložených v hlavičkách sekcí.

Obrázek 4.10

Dělený dutinový virus.

Jedním ze speciálních problémů těchto virů je skutečnost, že obsah přepsaných oblastí nemůže být stoprocentně obnoven. K tomu dochází hlavně v případě virů, které přepíší oblast souboru, která obvykle obsahuje nuly, nicméně v tomto konkrétním případě obsahuje něco jiného. Potom nebudou kryptografické kontrolní součty po vyléčení souboru odpovídat. Také se zkomplikuje přesná identifikace takových virů, protože je nutné, aby byly kousky kódu poskládány dohromady.

Detekce takových virů je založena na obsahu zaváděcí rutiny, která musí být uložena v jediné části kódu.

134

Kapitola 4 – Klasifikace metod infekce

4.2.8 Komprimující viry Tato speciální virová technika využívá možnosti zkomprimovat obsah hostitelského programu. Binární zkomprimování hostitele se někdy používá pro skrytí nárůstu délky infikovaného souboru. Komprimující viry se občas nazývají "užitečnými" ;-), protože dovedou zkomprimovat svého hostitele o mnoho více, než jej prodloužit, čímž šetří místo na disku. Tzv. runtime komprimační programy, jako PKLITE, LZEXE, UPX nebo ASPACK, jsou velmi oblíbené, nicméně jsou často zneužívány útočníky pro zkomprimování trojských koní, počítačových virů a červů tak, aby byly menší a daly se hůře analyzovat.

DOSový virus Cruncher byl první, který přišel s kompresní technikou. Některé 32bitové viry pro Windows ji také používají, jako třeba W32/HybrisF (souborový infektor červa Hybris ve formě plug-inu), jehož autor si říká Vecna. Dalším nechvalně známým představitelem je W32/Aldebera, který kombinuje metody infekce s polymorfismem. Aldebera se snaží zkomprimovat hostitele tak, že jeho velikost zůstane po infekci stejná. Byl vytvořen v roce 1999 členem virové skupiny IKX B0/S0 (Bozo).

Virus W32/Redemption napsaný Jackem Qwertmy také používá kompresní techniku k infekci 32bitových PE souboru na Windows. Obrázek 4.11 znázorňuje, jak komprimující viry útočí na soubory.

Obrázek 4.11

Komprimující virus.

4.2.9 Infekce typu Amoeba Amoeba je typ neobvyklé techniky infekce, která připojuje hostitelský program doprostřed virového těla. To se učiní připojením hlavičky viru na začátek a konec hostitele. Původní program se zrekonstruuje, uloží a spustí jako nový soubor na disku. Tuto techniku používá k infekci PE souborů na systémech Windows například virus W32/Sand.12300, vytvořený autorem Alcopaul a naprogramovaným ve Visual Basicu.

Na obrázku 4.12 je vidět hostitelský program před a po infekci virem, který používá techniku Amoeba.

Počítačové viry – analýza útoku a obrana

Obrázek 4.12

135

Technika infekce typu Amoeba.

4.2.10 Technika přidání decryptoru Některé viry vkládají do kódu své oběti decryptor, na který přesměrují vstupní bod programu. Umístění decryptoru je zvoleno náhodně a samotný decryptor se rozdělí na více částí. Přepsané bloky se uloží do virového kódu pro následné spuštění hostitelského programu ihned po provedení infekce.

Jakmile dojde ke spuštění infikované aplikace, jako první přijde na řadu decryptor, který rozšifruje zašifrované tělo viru a předá mu řízení. Slovenský polymorfní virus One_Half (květen 1994) tuto techniku používal k infekci DOSových COM a EXE souborů. Správná infekce EXE souboru touto technikou je složitější. Jestliže se relokace vztahují na část kódu, který byl přepsán virem, může se decryptor v paměti porušit, což může po spuštění hostitelského programu způsobit problémy.

Na obrázku 4.13 je vidět rozmístění decryptoru v infikovaném programu, který připomíná díry v ementálu. Snaha o detekci takových virů učinila skenovací kód více komplikovaným. Skener musí pro správnou detekci najít buď všechny rozmístěné bloky decryptoru nebo použít nějakou vyspělejší skenovací techniku, jakou je třeba emulace kódu (tyto techniky jsou dále rozvedeny v kapitole 11).

136

Obrázek 4.13

Kapitola 4 – Klasifikace metod infekce

Infekce připomínající ementál.

Nejjednodušší způsob pro analýzu takových virů je založen na použití speciálních pomocných souborů, které jsou vyplněny jedním vzorem, třeba znakem 0x41 ("A"). Po záměrné infekci za účelem testování můžeme vidět, jakým způsobem virus soubor přepsal: 142F:0D80

41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41

AAAAAAAAAAAAAAAA

142F:0D90

41 41 41 41 41 2E FD 16-2E F9 FB 36 E9 77 FD 41

AAAAA......6.w.A

142F:0DA0

41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41

AAAAAAAAAAAAAAAA

142F:0DB0

41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41

AAAAAAAAAAAAAAAA

142F:0DC0

41 41 41 41 41 41 41 41-41 3E 2E BB 88 14 2E F9

AAAAAAAAA>......

142F:0DD0

EB 9B 41 41 41 41 41 41-41 41 41 41 41 41 41 41

..AAAAAAAAAAAAAA

Všimněte si bajtů 0xE9 (JMP) a 0xEB (JMP short) v předešlém výpisu decryptoru viru One_Half, jedná se o ukazatele na další blok decryptoru. Antivirové programy dříve rekonstruovaly celý decryptor následováním těchto ukazatelů a pak jej mohly správně identifikovat a dešifrovat.

4.2.11 Technika vložení decryptoru a virového těla Sofistikovanější techniku infekce používal bulharský virus Commander_Bomber, jeden z posledních virů vytvořený Dark Avengerem ke konci roku 1993. Virus dostal své jméno díky řetězci, který je uložený ve virovém těle: COMMANDER BOMBER WAS HERE. Tělo viru Commander_Bomber je rozděleno do několika částí, které jsou náhodně rozmístěny v hostitelském programu (původní obsah je přepsán). Hlavička virového kódu začíná na začátku souboru a ta předává řízení dalšímu kusu kódu a tak to pokračuje dál, až k poslednímu. Tyto kusy kódu přepíší hostitelský program podobným způsobem, jakým to dělá virus One_Half. Přepsané části jsou pak uloženy na konci souboru a k jejich přístupu se používá tabulka.

Obrázek 4.14 znázorňuje umístění virového kódu v hostitelském programu. Skenery musí následovat spirálu toku vykonávání kódu, dokud nenaleznou hlavní tělo viru.

Počítačové viry – analýza útoku a obrana

Obrázek 4.14

137

Infekce ve stylu viru Commander_Bomber.

Řídící bloky jsou polymorfní, generované pomocí DAME (Dark Avenger Mutation Engine), který je součástí viru. To činí bloky velmi obtížně čitelné, protože obsahují hromadu falešného kódu a různých triků, kterými se předává řízení dalšímu bloku, dokud se nenarazí na rozšifrované tělo viru. Řízení tedy pokračuje hlavním tělem viru, které může být prakticky kdekoliv (ne nutně na konci souboru). To je hlavní výhodou těchto virů, protože skenery musí najít místo, kde je tělo uloženo. O rekonstrukci hostitelského programu se po spuštění postará samotný virus. V roce 1993 byla tato technika tak sofistikovaná, že pouze několik málo skenerů bylo schopno tento virus efektivně detekovat.

4.2.12 Technika matoucího odskoku W32/Donut, první virus schopný infikovat spustitelné soubory platformy .NET, nebyl závislý na JIT (Just-In-Time) kompilaci probrané v kapitole 3. To proto, že první verze spustitelných formátů .NETu mohou být napadeny skrz svůj programový vstupní bod, který zůstal závislý na architektuře (novější verze Windows by už neměly tento platformově závislý kód obsahovat a o správné zavedení aplikace by se měl starat systémový zavaděč).

W32/Donut získá kontrolu nad vykonáváním okamžitě po spuštění napadeného .NET PE souboru. Virus k útoku použije tu nejjednodušší možnou techniku – přemění program na obyčejný PE soubor tak, že vynuluje položku popisující CLR hlavičku v datovém adresáři PE hlavičky. Šestibajtový skok na importovanou položku _CorExeMain() ve vstupním bodu .NETového souboru nahradí virus skokem na svůj vstupní bod, přičemž původní vstupní bod v hlavičce ponechá (funkce _CorExeMain() se používá pro nastartování CLR prostředí a počátku vykonávání MSIL kódu). Této technice se říká matoucí odskok, protože dovede zmást některé heuristické skenery.

Skok ve vstupním bodě se nahradí operačním kódem 0xE9 (JMP) následovaným offsetem začátku virového těla na prvním bajtu relokační sekce, jak znázorňuje obrázek 4.15.

138

Obrázek 4.15

Kapitola 4 – Klasifikace metod infekce

Použití techniky matoucího odskoku.

Matoucí odskok je běžnou virovou technikou k zamezení změny původního vstupního bodu v hlavičce programu. Jedním z prvních virů, který začal tuto techniku používat, byl DOSový COM infektor Leapfrog, který následoval instrukci skoku na začátku hostitelského programu a vložil na jeho offset svůj vlastní skok na vstupní bod, jak je vidět na obrázku 4.15.

První dokumentovaný Win32 virus pojmenovaný jako W32/Cabanas11 používal tuto techniku k napadení PE souborů pro Windows 95 a Windows NT a ke zmatení heuristiky.

Po aktivaci W32/Donut zobrazí dialogové okno se zprávou, viz obrázek 4.16.

Obrázek 4.16

Dialogový box od viru W32/Donut.

Poznámka Autor viru svůj výtvor pojmenoval jako ".dotNet", ale protože se jedná o jméno platformy, nemůže zároveň sloužit jako jméno pro virus, jiné viry také nejmenují "DOS", "Windows" atd. Proto jsem zvolil jméno, které zní podobně jako původní označení "dotNET" a pojmenoval jsem jej jako Donut.

Počítačové viry – analýza útoku a obrana

139

4.2.13 Technika utajení vstupního bodu (EPO) Viry používající techniku utajení svého vstupního bodu (tzv. EntryPoint Obscuring, EPO) nemění při infekci vstupní bod aplikace a ani kód, na který ukazuje. Místo toho se snaží změnit původní programový kód tak, že virus převezme řízení v náhodný moment.

4.2.13.1 Základní EPO techniky pod DOSem Některé viry používají EPO techniky pod DOSem proto, aby omezily jednoduchou detekci rychlými skenery, které kontrolují programy těsně u jejich vstupních bodů. Například v roce 1997 virus Olivia12 infikoval DOSové EXE a COM soubory s použitím této metody. Tato technika začala být velmi populární mezi autory virů, protože dokázala po roce 1995 obelstít heuristické analyzátory.

Olivia infikuje soubory COM a EXE v okamžiku, jakmile jsou spuštěny nebo přejmenovány nebo v okamžiku, kdy jsou měněny jejich atributy. Virus nejprve vymaže souborové atributy, soubor otevře a zanalyzuje jeho strukturu.

Obrázek 4.17 představuje jednoduchý pohled na program infikovaný EPO virem.

Obrázek 4.17

Typický zakódovaný DOSový EPO virus.

Pokud má oběť příponu COM, Olivia použije speciální funkci, která ve smyčce přečte 4 bajty od začátku souboru a pokusí se vyhledat instrukce 0xE9 (JMP), 0xEB (JMP short), 0x90 (NOP), 0xF8 (CLC), 0xF9 (STC), 0xFA (CLI), 0xFB (STI), 0xFC (CLD) a 0xFD (STD). Pokud jednu z nich najde, vyhledá na místě další takovou instrukci. Pokud není umístěna v posledních 64 bajtech hostitele, virus jej přepíše na místě předešlé nalezené instrukce.

Olivia používá operační kód 0x68 (Intel 286 PUSH) pro uložení slova na zásobník. Po něm následuje instrukce 0xC3 (RET), která předá řízení virovému kódu vyzvednutím zasunutého offsetu decryptoru ze zásobníku.

(0x68) PUSH offset DECRYPTOR (0xC3) RET

140

Kapitola 4 – Klasifikace metod infekce

Na obrázku 4.17 je vidět instrukce skoku, která předá řízení decryptoru umístěnému na konci souboru, následovaná zašifrovaným virovým tělem. Viry často používají instrukce jako třeba CALL pro předání řízení začátku virového těla.

Na obrázku 4.18 je vidět zpráva přející všechno nejlepší k narozeninám, kterou zobrazí virus Olivia po své aktivaci.

Obrázek 4.18

Payload viru Olivia.

4.2.13.2 Vylepšené EPO techniky pod DOSem Virus Nexiv_Der13 (obrázek 4.19) je polymorfní v COM souborech a dokáže také infikovat diskové boot sektory. Nejzajímavější je ovšem na něm jeho speciální EPO technika, kterou používá při infikování souborů. Nexiv_Der byl pojmenovaný podle řetězce, který je uveden v zašifrovaném těle: "Nexiv_Der takes on your files".

Tento virus trasuje volání programu podobným způsobem, jako to dělají debuggery. Potom přepíše kód na náhodně zvolené instrukci CALL tak, aby ukazoval na polymorfní decryptor viru.

Cesta vykonávání programu záleží na mnoha parametrech, včetně argumentů předaných pomocí příkazové řádky a verze DOSu. V závislosti na těchto parametrech také dojde nebo nedojde k aktivaci viru.

Virus se nemusí ani jednou spustit na odlišné verzi DOSu, třeba z toho důvodu, že nezíská řízení. Tím vzniká velký problém i pro sofistikované heuristické skenery, které používají virtuální systém pro simulaci vykonávání programu, protože je obtížné emulovat všechna systémová volání a větve napadeného programu.

Hlavní myšlenka viru Nexiv_Der je založena na zavěšení se na obsluhu INT 1 (TRACE) pod DOSem. Tento handler je opravdovou infekční rutinou – trasuje hostitelský program po prvních 256 instrukcí a zastaví se po maximálním počtu 2048 iterací. Pokud byla poslední trasovaná instrukce 0xE8, 0xE9 nebo 80C0..CF (CALL, JMP, ADD AL,byte … OR BH,byte), pak ji Nexiv_Der nahradí instrukcí CALL směřující na virový kód na konci souboru. Obrázek 4.19 znázorňuje pohled na spustitelný soubor infikovaný tímto virem.

Počítačové viry – analýza útoku a obrana

Obrázek 4.19

141

Polymorfní EPO virus.

Hlavní výhodou této techniky je zvýšená pravděpodobnost vykonání virového kódu v podobném hostitelském prostředí, nicméně jedná se o tak komplikovanou techniku, že se používá jen velmi zřídka.

4.2.13.3 EPO viry na 16bitových Windows Jedním z prvních EPO virů běhajících po světě byla rodina Tentacle_II14 na systémech Windows 3.x.

Tento virus nijak nemění původní vstupní bod v NE hlavičce, která je obvyklým cílem virů pro 16 bitové Windows. Jak tedy převezme řízení? Virus využívá NE struktury a ačkoliv je to komplikovanější, poskytuje útočníkovi mnohem více možností pro spolehlivé vložení kódu do toku vykonávání. Tentacle_II využívá k nalezení běžného volání funkce (která je hostitelským programem vykonána mezi prvními) tabulky referencí modulů.

Tentacle_II v této tabulce najde moduly KERNEL a VBRUN300, získá jejich modulové číslo a pro každý segment přečte relokační záznamy. Potom vyhledá relokační záznam 91 (INITTASK) v případě modulu KERNEL nebo 100 (THUNKMAIN) v případě modulu VBRUN300. Oba tyto relokační záznamy ukazují na standardní inicializační rutinu, která se volá při každém startu Windows aplikace. Například u původního KEYVIEW.EXE (standardní Windows aplikace) vypadá relokační položka KERNEL.91 prvního segmentu takto: type

offset

target

PTR

0053h

USER.1

OFFS

007Eh

KERNEL.178

PTR

0073h

FAXOPT.12

PTR

00D3h

USER.5

PTR

005Bh

FAXOPT.44

PTR

00CAh

KERNEL.30

PTR

0031h

USER.176

PTR

00A0h

KERNEL.91 (INITTASK)

PTR

008Eh

KERNEL.102

Relocations: 9

Kapitola 4 – Klasifikace metod infekce

142

Jakmile dojde k infekci KEYVIEW.EXE, virus přepíše tento záznam tak, aby ukazoval na nový segment VIRUS_SEGMENT. Relokační záznamy segmentů: a.) Relokace segmentu 0001h type

offset

target

PTR

0053h

USER.1

OFFS

007Eh

KERNEL.178

PTR

0073h

FAXOPT.12

PTR

00D3h

USER.5

PTR

005Bh

FAXOPT.44

PTR

00CAh

KERNEL.30

PTR

0031h

USER.176

PTR

00A0h

0003h:002Eh (VIRUS_SEGMENT:2Eh)

PTR

008Eh

KERNEL.102

Relocations: 9 b.) Relokace segmentu 0003h (VIRUS_SEGMENT) type

offset

target

PTR

2964h

SHELL.6 (REGQUERYVALUE)

PTR

2968h

SHELL.5 (REGSETVALUE)

PTR

296Ch

KERNEL.91 (INITTASK -> STARTHOST)

Relocations: 3

Infikovaný soubor tedy začíná stejně jako před infekcí, ale jakmile aplikace zavolá jednu z předcházejících inicializačních funkcí, předá se řízení na adresu, kde začíná tělo viru.

VIRUS_SEGMENT má tři relokační záznamy. Jeden z nich bude ukazovat na původní inicializační rutinu KERNEL.91 nebo VBRUN300.100. Takto je virus schopen – po spuštění hostitele – aktivovat sám sebe. Tento druh infekce tedy používá techniku NE-EPO, která virus Tentacle_II činí odolným proti heuristickým skenerům.

Předchozí analýza byla provedena s pomocí utility TDUMP (Turbo Dump) od Borlandu. V dalších částech této kapitoly si podobné nástroje představíme zblízka a vysvětlíme si, jakou roli hrají při analýze virů.

Payload viru Tentacle_II je na obrázku 4.20. Virus vytvoří na disku soubor TENTACLE.GIF, který se zobrazí vždy, když je na infikovaném systému prohlížen libovolný obrázek v tomto formátu.

Počítačové viry – analýza útoku a obrana

Obrázek 4.20

143

Payload viru Tentacle_II.

4.2.13.4 Zavěšování se na API volání ve Win32 Na systémech Win32 byly EPO techniky velmi výrazně vylepšeny. Souborový formát PE15 může být napaden různými způsoby. Nejběžnější technika je založena na instrukcích, které se zavěsí na kód v kódové sekci programu. Typická Win32 aplikace volá mnoho API (Application Program Interface, aplikační rozhraní programu) funkcí a Win32 EPO viry těchto volání zneužívají tak, že je přesměrují na svůj vlastní kód.

Například viry W32/CTX a W32/Dengue od autora, který si říká GriYo, vyhledají instrukce CALL v kódové sekci hostitelského programu, které směřují do adresáře importů. Takto virus dovede spolehlivě identifikovat volání, které směřují do příslušných funkcí. CALL instrukce se tedy změní tak, aby ukazovaly na začátek virového kódu, který je umístěn jinde, typicky na konci souboru. Takové viry obvykle hledají jednu nebo obě implementace API volání: 

Implementace API volání od Microsoftu: CALL DWORD PTR []



Implementace API volání od Borlandu: JMP DWORD PTR []

Tento druh viru také volí zavěšení na API zcela náhodně; v některých případech nemusí virus získat řízení při žádném ze spuštění hostitelského programu. Jiné rodiny počítačových virů se zajišťují tak, že virus z programu bude aktivován nejčastěji.

Viry se mohou zavěsit na API volání, které se volá při každém ukončování programu – takovou API funkcí je ExitProcess(). Nahrazením API volání ExitProcess() voláním virového těla si virus zajistí spolehlivější aktivaci, kdykoliv aplikace ukončí svou činnost. Aby se detekce ještě více znesnadnila, viry kombinují EPO techniky s technikami matení kódu, jakými jsou třeba šifrování nebo polymorfismus.

Obrázek 4.21 znázorňuje Win32 EPO virus, který nahradí API volání ExitProcess() voláním virového kódu. Poté, co virus převezme řízení, spustí původní kód opravením přepsané instrukce.

Kapitola 4 – Klasifikace metod infekce

144

Obrázek 4.21

EPO virus, který se zavěsí na API volání hostitele.

Je normální, že se při ukončování aplikace zvýší disková aktivita. To se děje z několika důvodů, například tehdy, když aplikace používala hodně virtuální paměti, operační systém musí provést mnohem více přestránkování, což zvýší znatelně aktivitu disku. Je proto pravděpodobné, že takový virus zůstane delší dobu neodhalen.

4.2.13.5 Zavěšování se na funkce ve Win32 Další běžnou technikou EPO virů je spolehlivé hledání volání funkce v kódové sekci aplikace. Protože instrukce CALL může být datovou částí jiné instrukce, nemůže virus korektně odlišit jednotlivé instrukce pouhým vyhledáním instrukce CALL Viry proto často kontrolují, jestli instrukce CALL směřuje na instrukce, které jsou typické pro programovou subrutinu, jako například následující kód: CALL Foobar Foobar: PUSH EBP MOV

; operační kód 0x55

EBP, ESP ; operační kód 0x89E5

Obrázek 4.22 znázorňuje nahrazení volání funkce Foobar() voláním začátku virového kódu. Funkce Foobar() začíná sekvencí 0x55 0x89 0xE5, která je snadno identifikovatelná jako vstupní bod funkce.

Někdy se také používá sekvence 0x55 0x8B 0xEC, která dělá v podstatě to samé. Tuto virovou techniku používají varianty viru W32/RaingSong (vytvořené autorem, který si říká Bumblebee).

Počítačové viry – analýza útoku a obrana

Obrázek 4.22

145

Zavěšení na volání funkce EPO virem.

Poznámka Ruský virus Zhengxi narozdíl od ostatních používá kontrolní součet předcházejících vzorů, aby učinil svůj kód více matoucím. Zhengxi používá vzor pro infikování DOSových EXE souborů s využitím EPO techniky.

4.2.13.6 Nahrazení tabulky importů ve Win32 Novější Win32 viry infikují spustitelné soubory tak, že kvůli převzetí řízení nemodifikují původní kód programu a namísto toho použijí techniku podobnou technice, kterou používá virus Tentacle_II pro 16bitová Windows.

Aby virus získal řízení, jednoduše změní záznamy v tabulce adres importů hostitelského PE souboru tak, že každé API volání skrz tabulku importů aktivuje virus, protože ten mu podvrhl upravenou verzi tabulky.

Tuto techniku používala rodina virů W32/Idele, kterou napsal autor Doxtor L, viz obrázek 4.23.

W32/Idele zapíše do prázdné oblasti kódové sekce programu malou rutinu, která alokuje paměť, tam rozšifruje virové tělo a spustí jej. Takto nemusí virus Idele vytvářet tabulku s adresami, které nesměřují do kódové sekce.

146

Obrázek 4.23

Kapitola 4 – Klasifikace metod infekce

EPO virus, který nahrazuje tabulku importů.

4.2.13.7 Trasování instrukcí ve Win32 Virus Nexiv_Der inspiroval mnohé moderní viry na 32bitových systémech Windows. V roce 2003 se objevily nové viry, které začaly používat EPO techniku hojně užívanou v dobách DOSu. Například rodina virů W32/Perenast16 umí trasovat hostitelské programy před samotnou infekcí tak, že je s pomocí Windows debug API spustí jako skrytý ladící proces.

4.2.13.8 Použití "neznámých" vstupních bodů Jinou technikou, kterou lze docílit aktivaci virového kódu ve smyslu EPO, zahrnuje spouštění kódu přes nepříliš známé vstupní body aplikace. Souborový formát Win32 PE obvykle spouští aplikace ze vstupního bodu MAIN uloženým v PE hlavičce – jedná se o položku PE.OptionalHeader.AddressOfEntryPoint. Programy tedy vždy začínají na této adrese.

Nebude ovšem žádným překvapením, že tato položka není jediným vstupním bodem, který systémový zavaděč spouští. Na systémech Windows NT a výše systémový zavaděč nejprve vyhledá v datovém adresáři PE hlavičky položky lokálního úložiště toků (Thread Local Storage, TLS). Pokud nějaké nalezne, nejprve je spustí a teprve až poté následuje hlavní vstupní bod programu.

Následující dva obrázky dialogových boxů pochází z programu TLSDEMO, který napsal Peter Ferrie.

Toto demo vytvořil v roce 2000, kdy během výzkumu heuristické analýzy objevil trik se vstupním bodem skrz TLS. Jakmile se aplikace spustí, zobrazí se zpráva jak z TLS, tak i z hlavního vstupního bodu.

Nejprve se spustí vstupní bod TLS, viz obrázek 4.24.

Počítačové viry – analýza útoku a obrana

Obrázek 4.24

147

Spuštění vstupního bodu TLS.

Když kliknete na tlačítko OK, přeskočíte k hlavnímu vstupnímu bodu, viz obrázek 4.25.

Obrázek 4.25

Následné spuštění hlavního vstupního bodu.

Tento trik jsem nejprve nechtěl vůbec prozradit, protože by mohl být zneužit k vývoji ještě šikovnějších virů. Autor Roy G Biv ovšem tento nedokumentovaný trik objevil a v roce 2003 jej úspěšně implementoval v některých svých virech z rodiny W32/Chiton17.

4.2.13.9 EPO viry založené na integrování kódu Velmi sofistikovanou virovou technikou infekce je integrování kódu. Virus, který používá tuto techniku, vloží svůj kód do prováděcího toku hostitelského programu s použitím EPO technik a smíchá svůj kód s kódem hostitele. Jedná se velmi komplikovaný proces, který vyžaduje kompletní zdisassemblování a zreassemblování hostitele. Je tedy naštěstí extrémně náročné takový virus naprogramovat. Disassemblování hostitele je výpočetně náročná operace, která vyžaduje mnoho paměti. Takové viry potřebují obnovit obsah hostitelského programu správnou relokací jak kódových, tak i datových sekcí. Virus W95/ Zmist napsaný ruským autorem, který si říká Zombie, tuto techniku využívá v celé své kráse. Vzhledem k pokročilosti a složitosti této techniky je jí v kapitole 7 věnováno více místa.

Obrázek 4.26 znázorňuje typický obsah souboru infikovaný pokročilým EPO virem s integrovaným virovým kódem.

148

Obrázek 4.26

Kapitola 4 – Klasifikace metod infekce

Polymorfní a metamorfní virus s technikou integrování kódu.

Integrovaný virový kód je v dnešní době hlavní výzvou pro skenery a virové analytiky. Je totiž zapotřebí prozkoumat celý obsah souboru. Virus je zamaskovaný v kódové sekci infikovaného hostitele a je velmi obtížné najít instrukci, která předává řízení začátku viru. V případě viru W95/Zmist není decryptor virového kódu na jednom místě, ale je náhodně rozmístněn po celém kódu, podobně jako virus One_Half a Commander_Bomber.

4.2.14 Možné budoucí techniky infekce: stavitelé kódu Po přečtení předchozí části se můžete ptát, jaká technika může být ještě komplikovanější a sofistikovanější, než je EPO technika integrace kódu. Tato část se zabývá myšlenkou, která zatím ještě nebyla viděna ani u těch nejsložitějších implementací známých počítačových virů. Virus, který se tomuto konceptu blíží nejvíce, je již zmiňovaný virus W95/Zmist. Zmist volá kód hostitelského programu, aby z něj vykonal instrukci návratu (RET). Tok kódu tedy směřuje do hostitelského programu a pak zase zpět.

Autor měl zřejmě v úmyslu tuto techniku vylepšit tak, aby se vytvořilo virové tělo na základě obsahu hostitelského programu. Předpokládejme tedy virus, který používá techniku vlastního vytvoření kódu, jak je to uvedeno na obrázku 4.27.

Počítačové viry – analýza útoku a obrana

Obrázek 4.27

149

Virus vytvářející si vlastní kód.

Tato myšlenka je založena na faktu, že každý program může v sobě obsahovat jinou sadu programů nebo sekvenci instrukcí. Takový virus bude moci zanalyzovat kód hostitelského programu takovým sofistikovaným způsobem, že tyto řetězce instrukcí opětovně použije ve svém kódu. Nemusí být ale jednoduché najít takový kód, který by spustil správný kód s přesným stavem registrů. Pro jednoduchou demonstraci myšlenky si představte jednoduchý virus, který bude v hostiteli hledat písmena V, I, R, U a S. Generátor viru by všechny tyto kusy zkopíroval do paměti, nicméně sám by musel být vystavěn z generických sekvencí kódu, čehož by se dalo docílit metamorfní technikou. A musel by se umět sám integrovat do kódu hostitelského programu.

Jak už jsme psali, vytvořit takový virus by bylo velmi složité, nicméně detekovat něco takového by bylo pro mnoho lidí velkou výzvou. (Pár členů z rodiny W95/Henky používá podobnou techniku, akorát bez EPO, což podstatně zjednodušuje jeho detekci.)

4.3 Důkladný pohled na Win32 viry S příchodem Windows 95 na trh18 se drasticky změnil svět antivirového výzkumu. Jedním z důvodů byl fakt, že mnoho DOSových virů nebylo schopno pod tímto novým operačním systémem správně fungovat. Některé viry používaly k replikaci stealth techniky a nedokumentované funkce DOSu. Mnoho jednoduchých virů bylo pochopitelně schopno fungovat dál, jako třeba Yankee Doodle, velmi úspěšný bulharský virus. Přesto se tvůrci virů pokoušeli i nadále vytvářet DOSové a boot viry s přidanou kompatibilitou s Windows 95. Protože většina autorů neměla dostatek hlubokých znalostí vnitřních mechanismů nového systému, hledali zkratky, které by jim umožnily vytvářet viry pro tuto platformu. A rychle na jednu přišli – makro viry, které nejsou obecně závislé na jednom operačním systému ani hardwaru.

Někteří mladí autoři virů si vystačili s psaním makro virů a vyvíjeli je donekonečna. Po napsání několika úspěšných makro virů je to přestalo bavit a skončili s jejich vývojem. Jiní se ale začali poohlížet po jiných výzvách a obvykle našli nové způsoby, pomocí kterých bylo možné systémy infikovat.

150

Kapitola 4 – Klasifikace metod infekce

První virus pro Windows 95, W95/Boza, se objevil ve stejném roce, kdy byly Windows 95 představeny veřejnosti. Byl vytvořen australským členem virové skupiny VLAD. Dalším autorům trvalo relativně dlouhou dobu, než se dokázali v novém systému zorientovat a tak první viry určené pro tento operační systém se objevily až někdy v roce 1997.

Například – první Win32 a Windows NT kompatibilní virus Cabanas, se objevil koncem roku 1997 a byl vytvořen stejným autorem, který rovněž vytvořil známý makro virus WM/Cap.A. Virus Cabanas je kompatibilní jak s Windows 9x, tak i s Windows NT a Win32s (virus je rovněž kompatibilní s Windows 98 a Windows 2000, ačkoliv nikdy nebyl autorem na těchto systémech testován, protože se tyto OS objevily až později). Cabanas tak přeměnil sen Microsoftu o vzájemné Win32 kompatibilitě v noční můru.

Ačkoliv bylo obtížné takové viry napsat, počítali jsme s tím, že DOSové souborové infektory budou časem nahrazeny jejich Win32 následníky. Tento přechod psaní počítačových virů byl kompletně završen v roce 2004. V dnešní době je výskyt makro virů velmi řídký – autoři jsou nyní zaměřeni na 32bitové a 64bitové viry pro Windows.

4.3.1 Win32 API a platformy, které je podporují V roce 1995 Microsoft představil Windows 95 jako svůj nový operační systém. Systém Windows 95 byl sice silně založen na technologiích Windows 3.x a DOSu, ale zároveň dal termínu Win32 konečně ten pravý význam.

Co je Win32? Původně programátoři ani nechápali rozdíl mezi Win32 a Windows NT. Win32 je název API – nic více, nic méně. Sada funkcí dostupná 32bitovým Windows aplikací je obsažena ve Win32 API. To je implementováno na různých platformách – jednou z nich je Windows NT, nejdůležitější Win32 platforma. Kromě DOSových programů dokážou Windows NT spouštět 16bitové Windows programy a znakové aplikace pro OS/2 verze 1.x (a s některým rozšířením jdou spouštět i programy založené na Presentation Manageru 1.3, pochopitelně – s několika omezeními). Windows NT také přišly s novým přenositelným souborovým formátem (Portable Executable, PE), který je velmi podobný, ne-li přímo založený na unixovém formátu COFF a dovede spouštět Win32 aplikace (které volají funkce ze sady Win32 API). Jak naznačuje slovo přenositelný, jedná se o přenositelný souborový formát, který je v současné době nejběžnější a nejdůležitější na systému Windows NT. Jiné platformy také dovedou spouštět Win32 aplikace. Jedna z nich vypuštěna dokonce před Windows NT a jmenuje se Win32s. Kdokoliv, kdo se pokoušel pro tuto platformu programovat, velmi dobře ví, že šlo o velmi nestabilní řešení.

Protože Windows NT byly robustním systémem, který vyžadoval silný hardware, nezískala si Win32 technologie své místo na trhu tak rychle, jak si Microsoft původně představoval. Tento proces skončil vývojem Windows 95, které už od počátku podporovaly PE formát. Implementace Win32 API tak byla ve Windows 95 mnohem lepší než ta, která byla použita platformou Win32s, nicméně, implementace ve Windows 95 rovněž nebyla úplně kompletní, jako třeba ve Windows NT. Dokud nebylo Windows NT věnováno tolik pozornosti, byly systémy Windows 9x hlavní Win32 platformou Microsoftu. Po Windows NT se objevily více populární Windows 2000 a Windows 98/ME, které byly po nějaké době nahrazeny Windows XP a bezpečnějšími edicemi Windows 2003 Server, které standardně podporují rozšíření .NET. Microsoft nyní hovoří o další verzi Windows s kódovým označením

Počítačové viry – analýza útoku a obrana

151

Longhorn. Všechny tyto zde uvedené operační systémy podporují Win32 API, které zajišťuje kompatibilitu mezi jednotlivými verzemi operačních systémů.

V neposlední řadě Win32 API a PE formát podporují také Windows CE (edice Windows Mobile), které se primárně používají v kapesních počítačích (PDA). Požadavky ohledně hardware pro chod Windows CE nejsou nijak náročné – jedná se o procesory Intel a AMD od typu 486 výše. Současné implementace zvládají i procesory typu SH3, ARM a Intel XScale.

A nyní k těm procesorům. Jak Windows NT, tak i Windows CE jsou schopny běžet na strojích s odlišnými procesory. Na různých procesorech se používá ten stejný souborový formát PE, ale právě kód pro vykonávání zůstává ve zkompilovaném binárním tvaru pro aktuální procesor a PE hlavička obsahuje informace o typu procesoru, který je ke spuštění zapotřebí. Všechny tyto platformy obsahují rozdílné implementace Win32 funkcí. Většina funkcí je podporována ve všech implementacích, takže je programy mohou volat bez ohledu na platformu, na které právě běží. Většina odlišností v API se váže na aktuální schopnosti systému a dostupného hardware. Například funkce CreateThread() pod Win32s vrátí vždy NULL. API ve Windows CE se skládají ze stovek funkcí, ale nepodporují takové triviální funkce, jako třeba GetWindowsDirectory(), protože ve Windows CE je jádro (kernel) navrženo tak, aby se dalo umístit do paměti ROM kapesního počítače. Kvůli různým hardwarovým omezením (Windows CE musí běžet na strojích se 2 nebo 4MB paměti a to bez harddisku) se Microsoft snažil vytvořit nový operační systém takovým způsobem, aby nebyl tak komplikovaný jako Windows NT nebo Windows 95.

Ačkoliv různé realizace Win32 API implementují různé API různým způsobem (popř. vůbec), obecně vzato není velkým problémem napsat jeden program, který bez problémů poběží na všech platformách podporující Win32 API. Autoři virů tento fakt pochopili také. Jejich první viry sice útočily pouze na Windows 95, ale časem jejich tvůrci přišli na to, jak infikovat PE soubory takovým způsobem, aby infikované programy byly schopny korektně běžet i pod systémy Windows NT/2000/XP. Většina virů pro Windows 95 závisela na chování tohoto systému a jeho funkcionalitě, jako jsou třeba věci okolo VxD (což je virtuální ovladač zařízení) nebo VMM (správce virtuálního stroje), ale některé z nich obsahují pouze drobné chyby, po jejichž opravení by se dalo docílit jejich správného fungování na dalších Win32 platformách (kromě Windows 95/NT).

Detekce takových virů není jednoduchým úkolem, jejich odstranění může být pro implementaci ještě obtížnější. To proto, že PE struktura je mnohem více komplikovaná než jiné spustitelné souborové formáty používané například DOSem nebo Windows 3.x. Na druhou stranu je tu fakt, že PE formát je mnohem lépe navržen než třeba NE. Během let 1995 až 2004 autoři virů využili tuto novou platformu opravdu dostatečně – objevilo se totiž více než 16 tisíc různých variant virů. Základní principy těchto virů se ovšem moc nezměnily. V následující části naleznete podrobnosti o technikách infekce souborového formátu PE z pohledu útočníka.

Poznámka Win64 je téměř stejné jako Win32, je ale určeno pro 64bitové Windows. Win64 se od Win32 liší v několika drobnostech, a to hlavně kvůli rozdílům, které jsou mezi hardwarovými platformami.

152

Kapitola 4 – Klasifikace metod infekce

4.3.2 Techniky infekce na 32bitových Windows Tato část popisuje rozdílné způsoby, jakými mohou 32bitové viry pro Windows infikovat různé druhy spustitelných programů používané systémy Windows 95 / Windows NT. Protože je nejpoužívanějším formátem PE, většina metod se vztahuje na něj. PE formát umožňuje virům přeskakovat z 32bitové platformy Windows na jinou. Zaměříme se zejména na konkrétní techniky infekce, které útočí na tento formát, protože u těchto virů se dá předpokládat, že budou použitelné i v budoucnu.

První viry pro Windows 95 měly část VxD, která vypouštěla (dropped) ostatní infikované objekty, jako třeba DOSové soubory EXE a COM nebo PE aplikace. Některé z těchto metod infekce se nevztahují na Win32 platformy na úrovni API. Například VxD bylo podporováno pouze ve Windows 9x a Windows 3.x, nikoliv však ve Windows NT. VxD moduly mají svůj vlastní 32bitový, lineárně spustitelný (linear executable, LE), souborový formát. Je zajímavé, že tento formát byl 32bitový už v době 16bitových Windows. Microsoft ve Windows 95 nemohl upustit od podpory VxD, zejména kvůli existenci mnoha ovladačů třetích stran, které byly naprogramovány pro obsluhu speciálního hardwaru. Souborový formát LE sice zůstal Microsoftem nedokumentován, nicméně existuje hned několik virů, například Navrhar, které umí tento formát korektně napadnout. Tyto techniky zde popíšu pouze zběžně, abyste získali představu o vývoji Win32 virů.

4.3.2.1 Úvod do souborového formátu PE V následující části si uděláme menší exkurzi do přenositelného souborového formátu PE, který Microsoft navrhl pro použití v operačních systémech založených na Win32 (Windows NT, Windows 95, Win32s a Windows CE). Několik dobrých popisů tohoto formátu je možné najít nejenom v MSDN, ale také v mnoha dalších knihách o Windows 95, takže formát PE vám zde popíšu pouze z pohledu nám známých technik infekce. Pro to, abyste porozuměli tomu, jak viry pro Win32 pracují, je potřeba chápat tento formát. Nemusíte se ale ničeho bát – je vcelku prostý.

PE formát bude v dohledné budoucnosti dále hrát velkou roli ve všech operačních systémech od Microsoftu. Je obecně známý fakt, že Windows NT v sobě nesou dědictví VAX VMS a UNIXu. Jak již bylo zmíněno výše, PE formát je velmi podobný formátu COFF (Common Object File Format), je ale o něco vylepšený. Říká se mu přenositelný, protože se stejný souborový formát používá na více platformách.

Nejdůležitější věcí, kterou byste o PE souborech měli vědět, je to, že spustitelný kód na disku je velmi podobný tomu, jak vypadá modul po načtení do paměti. To systémovému zavaděči podstatně usnadňuje práci. V 16bitových Windows musel zavaděč strávit mnoho času přípravou kódu pro jeho spuštění.

To proto, že v případě 16bitových aplikací pro Windows se musely všechny funkce, které volají DLL (dynamicky zaváděné knihovny), vždy relokovat. Některé větší aplikace mohou mít tisíce relokací pro API volání, které musí systémový zavaděč opravit, přičemž současně čte soubor po oblastech do paměti a alokuje paměťové struktury jednu po druhé. PE aplikace nemusí volání DLL relokovat – místo toho se používá speciální oblast v PE souboru, tzn. tabulka importovaných adres (IAT, Import Address Table).

IAT hraje velkou roli u Win32 virů a její popis bude následovat později.

Ve Win32 je všechna paměť použita modulem pro kód, data, zdroje, tabulku importů a exportů v jednom spojitém, lineárně adresovacím, prostoru. Jedinou věc, kterou aplikace zná, je paměťová adresa, na

Počítačové viry – analýza útoku a obrana

153

kterou zavaděč namapoval spustitelný soubor. Jakmile je známa základní adresa, dají se zbývající kousky modulu najít následováním záznamů v PE souboru.

Další věc, se kterou byste měli být seznámeni, je relativní virtuální adresa, neboli RVA. Mnoho položek v PE souborech se udává v RVA, což je jednoduše offset položky, kde je soubor namapován. Například zavaděč může načíst PE soubor na adrese 0x400000 (nejčastější základní adresa) do virtuálního adresovacího prostoru. Pokud nějaká položka začíná na adrese 0x401234, bude RVA této položky 0x1234.

A potom tu máme ještě tzv. sekce. Sekce je v PE souboru ekvivalentem segmentu ze 16bitového NE souboru a obsahuje kód, popř. data (v některých případech obojí). Některé sekce obsahují kód nebo data deklarované aplikací, jiné obsahují důležité informace pro operační systém. Před zabíháním do podrobností se prosím podívejte na obrázek 4.28, který znázorňuje obecnou strukturu PE souboru.

4.3.2.1.1 PE hlavička První důležitou částí PE formátu je PE hlavička. Podobně jako všechny ostatní spustitelné souborové formáty od Microsoftu má PE soubor hlavičku, která obsahuje položky na konkrétních místech. PE hlavička popisuje životně důležité části přenositelného spustitelného programu. Nezačíná ale na samém začátku souboru – tam je starý DOS stub program (pozn. překl.: jedná se o pomocný program, jakýsi "roub", na který se roubují jiné části kódu).

DOS stub je krátký DOSový EXE program, který zobrazuje chybovou hlášku (obvykle "This program cannot be run in DOS mode"). Protože je tato hlavička umístěna na začátku souboru, některé DOSové viry infikují PE aplikace za stubem. Zavaděče systémů Windows 95 a Windows NT ovšem načítají PE aplikace jako 32bitové programy, takže tento DOSový program tam zůstává pouze kvůli kompatibilitě s 16bitovými systémy Windows.

Zavaděč si přečte adresu PE hlavičky z položky lfanew DOSové hlavičky. PE hlavička začíná důležitou magickou hodnotou PE\0\0, po níž následuje záhlaví souboru (file header) a nepovinné záhlaví (optional header).

Zde popíši pouze důležité položky PE hlavičky, které se týkají Windows 9x/Win32 virů. Tyto položky jdou sice podle pořadí, nicméně se zaměřím pouze na ty nejčastěji používané, takže tam budou některé chybět.

Obrázek 4.28 obecně znázorňuje strukturu PE souboru.

Kapitola 4 – Klasifikace metod infekce

154

Obrázek 4.28

Struktura PE souboru.

Následuje seznam důležitých položek souborové hlavičky. 

WORD Machine (Stroj) Označuje procesor, pro který je soubor určený. Mnoho virů pro Windows 9x před samotnou infekcí souboru kontroluje tuto položku, zda-li obsahuje hodnotu značící Intel i386. Některé viry to ovšem nedělají, infikují PE soubory pro jiné platformy a způsobí tak pád programu ihned poté, co se k vykonávání dostane virový kód. Je pravděpodobné, že se v budoucnu dočkáme virů

Počítačové viry – analýza útoku a obrana

155

s podporou více procesorů – některé viry například budou útočit na soubory určené nejenom pro procesory ARM, ale také pro I64 a X86. 

WORD NumberOfSections (Počet sekcí) Počet sekcí v EXE (DLL). Viry používají tuto položky z mnoha důvodů. Například inkrementují položku NumberOfSections vždy, když do PE souboru přidávají novou sekci, kam se uloží tělo viru (když virus změní tuto položku, musí také upravit tabulku sekcí). Systémy založené na Windows NT podporují až 96 sekcí, systémy Windows 95 toto číslo nekontrolují.



WORD Characteristics (Příznaky) Příznaky souboru. Mnoho virů ověřuje tyto příznaky, aby se ujistily, že se jedná o EXE soubor, a nikoliv o DLL knihovnu (některé viry pro Windows 9x, které infikují KERNEL32.DLL, se naopak ujišťují, že se jedná o DLL). Viry tuto položku obvykle nemění.

Následují důležité položky volitelné hlavičky. 

WORD Magic (Magické slovo) Volitelná hlavička začíná "magickou" hodnotou. Některé viry kontrolují tuto položku proto, aby infikovaly jen obyčejné spustitelné soubory a nikoliv ROM image nebo něco jiného.



DWORD SizeOfCode (Velikost kódu) Tato položka uvádí zaokrouhlenou velikost všech spustitelných sekcí. Viry obvykle tuto hodnotu nijak neupravují, pokud do hostitele přidávají vlastní část kódu. Očekává se, že budoucí viry budou měnit tuto hodnotu.



DWORD AddressOfEntryPoint (Adresa vstupního bodu) Adresa, na které program začíná. Tato hodnota je RVA, která normálně ukazuje do sekce .text (nebo CODE). Jedná se o klíčovou položku pro většinu Windows 9x/Win32 virů, po jejíž změně je možné přesměrovat vstupní bod programu na kód viru.



DWORD ImageBase (Bázová adresa modulu) Když linker vytváří spustitelný PE soubor, předpokládá, že bude namapovaný na konkrétní paměťovou adresu, která je uložena v této položce. Pokud se dá načíst na uvedenou adresu (0x400000 v programech Microsoftu), potom zavaděč nepotřebuje provést relokační opravy.

Tuto položku používá většina virů před infekcí pro výpočet adres některých prvků, obvykle jí nemění.



DWORD SectionAlignment (Zarovnání sekce v paměti) Jakmile je soubor namapován do paměti, musí každá sekce začínat na virtuální adrese, která je násobkem této hodnoty. Její minimum je 0x1000 (4096 bajtů), ale linkery od Borlandu používají větší násobky, jako třeba 0x100000 (64KB). Většina Win32 virů tuto položku používá pro výpočet správného umístění virového těla, ale nijak do ní nezasahují.



DWORD FileAlignment (Zarovnání sekce v souboru)

Kapitola 4 – Klasifikace metod infekce

156

V PE souboru začínají vlastní data na násobku této hodnoty. Viry ji neupravují, ale používají podobným způsobem jako v případě SectionAlignment. 

DWORD SizeOfImage (Velikost modulu) Když linker sestavuje soubor, vypočítá celkovou velikost částí souborů, které musí zavaděč načíst. To zahrnuje velikost oblasti od začátku modulu až po poslední sekci. Konec poslední sekce bývá zaokrouhlen na nejbližší násobek zarovnání sekce. Téměř každá metoda infekce PE používá a mění tuto hodnotu v PE hlavičce.

Není překvapením, že existuje mnoho virů, které tuto hodnotu nepřepočítávají správně, což znemožňuje běh napadených souboru pod systémem Windows NT. To proto, že zavaděč systému Windows 9x se neobtěžuje s kontrolováním této hodnoty. Autoři virů totiž velmi málo testují své výtvory (pokud vůbec), a tak většina virů pro Windows 95 obsahuje nějakou chybu. A také některý antivirový software může po vyléčení souboru nesprávně změnit tuto hodnotu, což vede k tomu, že Windows NT kompatibilní aplikace se spustí pouze na Windows 9x (i když už neobsahuje žádný virový kód).



DWORD Checksum (Kontrolní součet) Jedná se o kontrolní součet souboru. Většina spustitelných souborů obsahuje nulu, ale všechny DLL knihovny a ovladače kontrolní součet mít musí. Zavaděč systému Windows 95 tuto položku během zavádění programu do paměti ignoroval, což některým virům pro Windows 95 usnadnilo infekci KERNEL32.DLL. Některé viry tuto položku používají pro označení již infikovaných souborů, aby předešly jejich vícenásobné infekci, jiné viry ji poctivě přepočítávají.

4.3.2.1.2 Tabulka sekcí a nejběžněji používané sekce Mezi PE hlavičkou a samotnými daty leží tabulka sekcí, která obsahuje informace o každé sekci PE souboru (viz následující výpisy provedené utilitou PEDUMP).

V zásadě se sekce používají proto, aby se od sebe oddělily různé funkční části programu, jako například spustitelný kód od dat, globálních dat, ladících informací, relokací a tak dále. Změna tabulky sekcí je pro viry důležitá, buď tam musí novou sekci přidat, nebo zvětšit nějakou stávající, aby se do ní virus vešel.

Každá sekce souboru má svoji vlastní hlavičku v tabulce sekcí. Tyto hlavičky popisují jméno sekce (.text, .reloc atd.), stejně jako její velikost nebo umístění surových (raw) dat. První generace virů, jako třeba Boza, přidávaly do tabulky novou sekci (.vlad), která uváděla pozici a velikost virové sekce.

Někdy v tabulce není místo pro další záznam a tak existuje možnost zvětšit poslední sekci (tak to dělají novější viry, jako třeba W95/Anxiety19), čímž virový kód přestane být tolik na očích a infekce nebude tak riskantní.

Následující výpis 4.1 obsahuje tabulku sekcí přečtenou z programu CALC.EXE (kalkulačka ze systému Windows).

Výpis 4.1 Náhled do tabulky sekcí programu CALC.EXE s pomocí PEDUMP. 01.text VirtSize: 000096B0 VirtAddr: 00001000

Počítačové viry – analýza útoku a obrana

157

raw data offs: 00000400 raw data size: 00009800 relocation offs: 00000000 relocations: 00000000 line # offs: 00000000 line #’s: 00000000 characteristics: 60000020 CODE MEM_EXECUTE MEM_READ 02 .bss VirtSize: 0000094C VirtAddr: 0000B000 raw data offs: 00000000 raw data size: 00000000 relocation offs: 00000000 relocations: 00000000 line # offs: 00000000 line #’s: 00000000 characteristics: C0000080 UNINITIALIZED_DATA MEM_READ MEM_WRITE 03 .data VirtSize: 00001700 VirtAddr: 0000C000 raw data offs: 00009C00 raw data size: 00001800 relocation offs: 00000000 relocations: 00000000 line # offs: 00000000 line #’s: 00000000 characteristics: C0000040 INITIALIZED_DATA MEM_READ MEM_WRITE 04 .idata VirtSize: 00000B64 VirtAddr: 0000E000 raw data offs: 0000B400 raw data size: 00000C00 relocation offs: 00000000 relocations: 00000000 line # offs: 00000000 line #’s: 00000000 characteristics: 40000040 INITIALIZED_DATA MEM_READ 05 .rsrc VirtSize: 000015CC VirtAddr: 0000F000 raw data offs: 0000C000 raw data size: 00001600 relocation offs: 00000000 relocations: 00000000 line # offs: 00000000 line #’s: 00000000 characteristics: 40000040 INITIALIZED_DATA MEM_READ 06 .reloc VirtSize: 00001040 VirtAddr: 00011000 raw data offs: 0000D600 raw data size: 00001200 relocation offs: 00000000 relocations: 00000000 line # offs: 00000000 line #’s: 00000000 characteristics: 42000040 INITIALIZED_DATA MEM_DISCARDABLE MEM_READ

Jméno sekce může být prakticky cokoliv, může obsahovat třeba samé nuly; zavaděč se o jméno nijak nezajímá. Obecně ale jméno popisuje to, k jakému účelu je sekce určena.

Asi to zde působit trochu zmatečně, ale sekce v PE souboru nesoucí spustitelný kód se obvykle pojmenovává jako .text a bývá v tabulce uložena jako první. Jedná se o tradiční jméno převzaté ze staršího COFF formátu. Linker v této velké sekci koncentruje veškerý obsah OBJ souborů a jak popíšu později, neobsahuje pouze čistý kód, ale také tabulku odkazů pro funkční volání DLL knihoven. Linker od Borlandu tuto sekci pojmenovává jako CODE, což sice není tradiční jméno, ale lépe popisuje účel sekce.

Jiným běžným jménem pro sekci je .data, kam se ukládají inicializovaná data. Sekce .bss obsahuje statické neinicializované globální proměnné, sekce .rsrc v sobě nese veškeré zdroje aplikace.

158

Kapitola 4 – Klasifikace metod infekce

Sekce .data obsahuje tabulku importů – jedná se o velmi důležitou část PE formátu pro viry. Zapamatujte si, že jednotlivé sekce slouží pouze jako logické oddělovače; protože nic není povinné – obsah sekce .idata může být klidně smíchán s jinou sekcí nebo tato sekce vůbec nemusí být přítomná.

Sekce .edata je velmi důležitá pro viry, protože obsahuje seznam všech API, které dotyčný modul exportuje jiným spustitelným modulům.

Sekce .reloc obsahuje tabulku bázových relokací. Některé viry dávají pozor při práci s relokačními záznamy spustitelných souborů, nicméně tyto sekce od dob vypuštění Windows 98 pomalu mizí. Tato sekce byla už svého od počátku poznamenána problémem ve vlastním návrhu – program se do paměti načítá ještě před DLL knihovnami a má svůj vlastní adresovací prostor, takže program tuto sekci v podstatě nepotřebuje.

A v neposlední řadě tu je sekce .debug, která obsahuje ladící informace spustitelného souboru (pokud ovšem nějaké má). Pro viry to není nic zajímavého, ačkoliv se také dá zneužít k infekci.

Protože programátor může jména sekcí libovolně specifikovat, některé spustitelné soubory standardně obsahují všechna možná speciální jména.

Z tabulky sekcí jsou pro viry nejdůležitější tyto položky: VirtualSize (virtuální velikost sekce), SizeOfRawData (velikost sekce v souboru zaokrouhlená na nejbližší násobek, viz FileAlignment) a Characteristics (příznaky sekce).

Položka Characteristics obsahuje sadu příznaků, které popisují atributy sekce (kód, data, čitelná, zapisovatelná, spustitelná atd.). Sekce kódu má příznak určující, že je spustitelná, ale už nemá atribut umožňující zápis, protože zapisovatelná data jsou umístěna v jiné sekci. Situace se ovšem mění po infekci virem, který potřebuje udržovat nějakou oblast s daty uvnitř kódu – musí tedy patřičně změnit položku Characteristics.

Z výše uvedeného vyplývá, že odstraňování 32bitových virů může být mnohem komplikovanější, než v případě obyčejného DOSového EXE viru. Samotná infekce sice není triviální záležitost, ale na internetu se nachází tolik zdrojových kódů virů, že autoři virů mají plnou podporu při vytváření nových virových variant.

4.3.2.1.3 Tabulka importů v PE: jak se DLL knihovny spojují se spustitelnými programy?

Většina virů pro Windows 9x a Windows NT je založena na procházení tabulky importů, která je velmi důležitou součástí PE struktury. V prostředí Win32 se všechny DLL knihovny spojují skrz tabulku importů s aplikacemi, které je používají. Tato tabulka obsahuje jména importovaných DLL knihoven a také jména importovaných funkcí z příslušných knihoven. Uvažme následující příklad: ADVAPI32.DLL Ordn Name 285 RegCreateKeyW 279 RegCloseKey KERNEL32.DLL Ordn Name 292 GetProfileStringW

Počítačové viry – analýza útoku a obrana

159

415 LocalSize 254 GetModuleHandleA 52 CreateFileW 278 GetProcAddress 171 GetCommandLineW 659 lstrcatW 126 FindClose 133 FindFirstFileW 470 ReadFile 635 WriteFile 24 CloseHandle 79 DeleteFileW

Spustitelný kód je umístěn v sekci .text (nebo CODE v případě linkeru od Borlandu). Jakmile aplikace volá funkci, která je umístěna v DLL knihovně, instrukce CALL nezavolá funkci přímo, ale namísto toho pokračuje dál v sekci instrukcí skoku (JMP DWORD PTR [XXXXXXXX]).

Adresa, na kterou instrukce skoku skáče, je uložena v sekci .idate (nebo někdy v .text) a jedná se o položku v IAT (Import Address Table, tabulka adres importů). Řízení se tedy předá kódu na adrese, na kterou ukazuje DWORD položka v IAT v sekci .idata, což je adresa příslušné funkce v DLL knihovně, jak je vidět v následujícím výstupu. Ve výpisu 4.2 aplikace volá funkci FindFirstFileA() z KERNEL32.DLL.

Výpis 4.2 Importované funkce. .text (CODE) 0041008E E85A370000 CALL 004137ED ; KERNEL32!FindFirstFileA 004137E7 FF2568004300 JMP [KERNEL32!GetProcAddress] ; 00430068 004137ED FF256C004300 JMP [KERNEL32!FindFirstFileA] ; 0043006C 004137F3 FF2570004300 JMP [KERNEL32!ExitProcess] ; 00430070 004137F9 FF2574004300 JMP [KERNEL32!GetVersion] ; 00430074 .idata (00430000) .

00430068 1E3CF177 ;-> 77F13C1E Entry of KERNEL32!GetProcAddress 0043006C DBC3F077 ;-> 77F0C3DB Entry of KERNEL32!FindFirstFileA 00430070 6995F177 ;-> 77F19569 Entry of KERNEL32!ExitProcess 00430074 9C3CF177 ;-> 77F13C9C Entry of KERNEL32!GetVersion

Volání jsou tímto způsobem implementována z toho důvodu, aby se zjednodušila a urychlila práce, kterou musí zavaděč vykonat. Přemostěním všech volání příslušné funkce v DLL knihovně na jedno místo odpadne zavaděči nutnost opravovat každou instrukci, která ji volá. Vše, co PE zavaděč musí udělat, je zapsat adresu každé funkce do IAT, což je v podstatě jen seznam DWORDů.

160

Kapitola 4 – Klasifikace metod infekce

Tabulka importů je pro moderní 32bitové viry velmi užitečná. Protože systémový zavaděč musí opravit adresy všech API, které Win32 program importuje, viry mohou jednoduše získat adresu API, kterou potřebují, pouhým nahlédnutím do tabulky importů hostitele.

Tento problém u tradičních DOSových virů neexistoval. Když chtěl DOSový virus zavolat systémovou službu, jednoduše zavolal příslušné přerušení s příslušným číslem funkce. Aktuální adresa přerušení byla umístěna v tabulce vektorů přerušení a data z ní se četla automaticky během vykonávání programu.

Tabulka vektorů přerušení byla dostupná všem programům – všechny aplikace z ní mohly číst a současně do ní zapisovat, protože v DOSu neexistovaly žádné úrovně oprávnění. Celý operační systém sdílí společně s aplikacemi stejnou paměť se stejnými právy – tudíž přístup k systémovým funkcím nedělal DOSovým virům vůbec žádný problém. Měly přístup ke všemu, co potřebovaly, bez ohledu na používanou metodu infekce.

Viry pro Windows 95 musí volat API nebo systémové služby, aby mohly správně fungovat. Většina 32bitových aplikací používá tabulku importů, kterou pro ně linker připravil. Existuje nicméně pár způsobů jak se obejít bez importů, což je mnohdy důležité z důvodu kompatibility. Když je aplikace spojená s DLL knihovnami, není možné program spustit, pokud zavaděč nemůže správně načíst všechny DLL knihovny specifikované v tabulce importů. Pokud se zavaděči nepodaří lokalizovat příslušné volání API (podle jména nebo ordinární hodnoty), rovněž nebude možné spustit danou aplikaci.

Některé aplikace musí tento problém nějak řešit. Například – pokud chce Win32 program získat seznam jmen všech běžících procesů pod Windows 95 a NT, musí pod Windows 95 použít systémovou DLL knihovnu a API volání, které jsou odlišné od těch na systému Windows NT. V tomto případě nemůže být aplikace svázaná k oběma DLL knihovnám, protože by se nespustila na žádném systému. Místo toho se použije funkce LoadLibrary(), která natáhne knihovnu do paměti a funkci GetProcAddress(), která zjistí adresu příslušného API. Program může volat API LoadLibrary() a GetProcAddress() prostřednictvím tabulky importů, čímž se řeší klasický problém se slepicí a vejcem – jak volat API pro získání adres bez znalosti její adresy.

Jak uvidíte později, virus Boza řeší tento problém používáním pevných adres API funkcí. Moderní Win32 viry ovšem umí během infekce prohledávat tabulku importů hostitele a uložit si důležité ukazatele do sekce .idata. Kdykoliv aplikace importuje příslušné API funkce, je připojený virus schopen je sám volat.

Poznámka Důležitým rozdílem mezi 64bitovými a 32bitovými PE soubory je v jejich obsluhování položek v tabulce importů a exportů. IA64 PE soubory používají strukturu PLABEL_DESCRIPTOR namísto IAT položek (tato struktura je podrobněji rozebrána v kapitole 12).

4.3.2.1.4 Tabulka exportů v PE Opakem importování funkce je exportování funkce, aby ji mohl použít EXE program nebo jiné DLL knihovny. PE soubor udržuje informace o exportovaných funkcích v sekci .edata. Uvažujme následující výpis, který obsahuje několik exportů z KERNEL32.DLL:

Počítačové viry – analýza útoku a obrana

161

Entry Pt Ordn Name 000079CA 1 AddAtomA .

0000EE2B 38 CopyFileA .

0000C3DB 131 FindFirstFileA .

00013C1E 279 GetProcAddress

Tabulka exportů knihovny KERNEL32.DLL se sestává ze struktury IMAGE_EXPORT_DIRECTORY, která obsahuje tři různé seznamy: tabulku adres funkcí, tabulku jmen funkcí a tabulku ordinárních hodnot funkcí. Moderní viry pro Windows 95/NT vyhledávají řetězec "GetProcAddress" v tabulce jmen, aby získaly adresu vstupního bodu API. Když se k této hodnotě přidá hodnota ImageBase, je výsledkem 32bitová adresa API v DLL knihovně. Ve skutečnosti se jedná o téměř shodný algoritmus, jaký interně používá funkce GetProcAddress() z KERNEL32.DLL. Tato funkce je jedna z nejdůležitějších pro viry pro Windows 95, které chtějí být kompatibilní s více než s jedním Win32 systémem. Jakmile virus získá adresu GetProcAddress(), může získat adresy všech API, které potřebuje.

4.3.2.2 První generace virů pro Windows 95 Prvním známým virem pro Windows 95 je W95/Boza.A, který byl představen v magazínu virové skupiny VLAD. Autoři se snažili přijít se svým výtvorem co nejdřív a tak museli sehnat nějakou beta-verzi Windows 95. První viry obsahovaly velmi mnoho chyb a Boza nebyl žádnou výjimkou. Virus v podstatě neuměl běžet na více než dvou verzích Windows 95 – na beta-verzi a finální verzi. Dokonce i na těchto dvou verzích Windows 95 virus během své replikace způsoboval mnoho obecných narušení ochrany a infikované soubory byly často porušené.

Boza je typickým připojujícím se virem infikujícím PE aplikace. Virové tělo se umístí v nové sekci nazvané .vlad, hlavička sekce se zapíše do tabulky sekcí jako poslední položka a položka v PE hlavičce popisující počet sekcí se příslušně inkrementuje. Tělo viru se připojí na konec hostitele a vstupní bod v PE hlavičce se přepíše adresou nové sekce.

Boza používá pevné adresy pro všechna API, která potřebuje volat. Jedná se o nejjednodušší a naštěstí také nejméně úspěšný způsob. Autoři viru pracovali nejprve na beta-verzi Windows 95 a používali pevné adresy příslušné implementace KERNEL32.DLL. Později si všimli, že virus není kompatibilní s finální verzí, protože Microsoft nemohl poskytovat stejné ordinární hodnoty a adresy všech API na všech systémech ve všech jejich vydáních. Různé implementace Windows 95 – bety, jazykové verze, OSR2 verze atd. – nemají stejné adresy API. Například první API volání ve viru Boza je GetCurrentDirectoryA(). Obrázek 4.29 ukazuje, jak se ordinární hodnoty a vstupní body GetCurrentDirectoryA liší na anglické verzi Windows 95 v porovnání s maďarskou OSR2 verzi.

162

Kapitola 4 – Klasifikace metod infekce

Entry Pt Ordn A. 00007744 304 GetCurrentDirectoryA (Windows 95 ENG) B. 0000774C 307 GetCurrentDirectoryA (Windows 95 OSR2-HUN)

Obrázek 4.29

Ordinární hodnoty dvou vydání Windows 95.

ImageBase (bázová adresa modulu) je v obou vydáních KERNEL32.DLL 0xBFF70000, ale adresa GetCurrentDirectoryA() je v anglické verzi 0xBFF77744 a v maďarské OSR2 verzi 0xBFF7774C. Pokud se Boza snaží replikovat na maďarské verzi, volá špatnou adresu a replikace se mu nezdaří. Proto se Boza nedá nazývat skutečným, Windows 95 kompatibilním virem, protože je nekompatibilní téměř se všemi verzemi Windows 95.

Bez ohledu na tento fakt se mnoho virů snaží pracovat s pevnými adresami API funkcí a mnohým z nich se nepovede vůbec rozšířit. Nyní se zdá, že autoři virů rozumí Win32 systémům mnohem lépe a dovedou vytvářet viry kompatibilní nejenom se všemi verzemi Windows 95, ale také s verzemi Windows 98 a Windows NT.

4.3.2.2.1 Infekce hlavičky Tento typ Windows 95 virů vkládá sám sebe mezi konec PE hlavičky (za tabulku sekcí) a začátek první sekce a modifikuje položku AddressOfEntryPoint v PE hlavičce tak, aby ukazovala na vstupní bod viru.

Prvním známým virem, který začal používat tuto techniku, byl W95/Murkry.

Virový kód musí být v případě infekce hlavičky velmi krátký. Protože sekce musí začínat na offsetu, který je násobkem položky FileAlignment, maximální možné místo na přepsání virem není větší než právě hodnota FileAlignment. Pokud aplikace obsahuje příliš mnoho sekcí a FileAlignment je velký 512 bajtů, virový kód se do ní nevejde. Položka AddressOfEntryPoint je RVA; virový kód nicméně není umístěn v žádné sekci, a proto je aktuální RVA viru fyzický offset v souboru. Je zajímavé, že vstupní bod neukazuje do žádné kódové sekce, ale bez ohledu na tento fakt, Windows 95 takto infikovaný soubor bez problémů spustí.

Existuje šance, že se některým skenerům nepodaří detekovat druhou generací takových virů. K tomu dojde, když se skener testuje pouze na prvních generacích virů. V těchto generacích AddressOfEntryPoint ukazuje na platnou sekci. Když skener ohledává vstupní bod programu, musí zkontrolovat, zda-li ukazuje do nějaké sekce uvedené v tabulce sekcí. Je možné, že tato funkce skeneru není implementována tak, aby dovedla pracovat se všemi případy změněných vstupních bodů – některé skenery mohou takový soubor přeskočit místo toho, aby jej začaly skenovat od pravého vstupního bodu, čímž by předešly neschopnosti detekovat vzorky infikovaných virů druhé generace.

4.3.2.2.2 Viry připojující se na začátek souboru Nejjednodušší způsob infekce PE souborů je realizován přepsáním jejich začátku. Některé DOSové viry sice takto infikují PE soubory, ale žádný virus pro Windows 95 tuto techniku nepoužívá. Je samozřejmé, že po takové infekci není program schopen fungovat. Z toho důvodu bývají takové viry objeveny téměř okamžitě, protože se jim nechce zpracovávat komplikovaný PE formát pro použití této připojovací techniku. Takové viry bývají obvykle napsány ve vyšším programovacím jazyku (HLL, High-Level Language), jakým je třeba C nebo Delphi. Metoda spočívá v připojení viru na začátek PE souboru tak,

Počítačové viry – analýza útoku a obrana

163

že infikovaný program startuje s EXE hlavičkou viru. Jakmile chce virus vrátit řízení původnímu programu, musí jej vyextrahovat do dočasného souboru a spustit.

Dezinfekce takových virů je jednoduchá. Původní hlavička je uložená na těsném konci infikovaného programu v nezašifrovaném formátu. Až si toto autoři virů uvědomí, pokusí se původní hlavičku zašifrovat, čímž učiní dezinfekci obtížnější.

4.3.2.3 Viry připojující se na konec souboru, které nepřidávají novou sekci S vylepšenou technikou připojování přišel virus W95/Anxiety, který je v mechanismu infekce podobný viru Boza, ale jeho kód je více podobný viru W95/Harry.

Virus Anxiety do tabulky nepřidává novou sekci, a místo toho upraví poslední sekci tak, aby se do ni vešel. Virus takto dovede jednoduše infikovat všechny PE soubory a nemusí se starat o to, jestli se hlavička nové sekce vejde do tabulky nebo ne.

Změnou položek VirtualSize a SizeOfRawData je možné virový kód umístit na konec spustitelného souboru a není potřeba měnit položku NumberOfSections. Změní se pouze položka AddressOfEntryPoint tak, aby ukazovala na virové tělo, přičemž se přepočítá položka SizeOfImage, aby reprezentovala novou celkovou velikost programu. Výpis 4.3 znázorňuje poslední sekci programu CALC.EXE před a po infekci virem W95/Anxiety.1358.

Výpis 4.3 Změna sekce virem W95/Anxiety.1358.

06 .reloc VirtSize: 00001040 VirtAddr: 00011000 raw data offs: 0000D600 raw data size: 00001200 relocation offs: 00000000 relocations: 00000000 line # offs: 00000000 line #’s: 00000000 characteristics: 42000040 INITIALIZED_DATA MEM_DISCARDABLE MEM_READ 06 .reloc VirtSize: 00002040 VirtAddr: 00011000 raw data offs: 0000D600 raw data size: 00001640 relocation offs: 00000000 relocations: 00000000 line # offs: 00000000 line #’s: 00000000 characteristics: E0000040 INITIALIZED_DATA MEM_EXECUTE MEM_READ MEM_WRITE

Položka Characteristics poslední sekce je změněna tak, aby měla atribut zapisovatelná/spustitelná. Atribut zapisovatelná stačí ke spuštění samomodifikujícího kódu, ale mnoho autorů virů to doposud nezjistilo.

Virus typu W32/Zelly používá dvě techniky infekce. V základním režimu Zelly přidá dvě nové sekce do hostitelského programu, ve vylepšeném režimu smíchá všechny přítomné sekce do jedné a přidá na její konec své tělo, čímž se těsněji integruje do hostitelského programu.

164

Kapitola 4 – Klasifikace metod infekce

4.3.2.4 Viry připojující se na konec souboru, které nemodifikují vstupní bod Některé viry pro Windows 95 a Win32 nemodifikují položku AddressOfEntryPoint v PE hlavičce infikovaného programu. Takové viry připojují svoje tělo na konec programu, ale řízení převezmou sofistikovanějším způsobem. Vypočítají si místo, kam ukazuje položka AddressOfEntryPoint a toto místo přepíšou instrukcí JMP, která povede na virové tělo. Naštěstí je už trochu obtížnější napsat takové viry.

To z toho důvodu, že viry musí dávat pozor na relokační záznamy, které ukazují do přepisované části kódu; třeba W32/Cabanas maskuje relokační záznamy, které do té oblasti kódu ukazují. W95/Marburg neumisťuje instrukci JMP na začátek vstupního bodu, pokud pro tu oblast najde relokační záznamy, a místo toho přímo modifikuje položku AddressOfEntryPoint. Instrukce JMP by neměla být první instrukcí programu. W95/Marburg toto řeší umístěním instrukce skoku za blok náhodného smetí (pokud u vstupního bodu nejsou přítomny relokace pro prvních 256 bajtů kódu). V tomto případě není vstupní bod viru zřejmý pro antivirové skenery a kontrolory integrity.

4.3.2.5 Infekce KERNEL32.DLL Většina virů pro Windows 95 útočí na PE formát, ale některé z nich také infikují DOSové COM a EXE programy, VxD moduly, dokumenty Wordu a 16bitové Windows NE aplikace. Jiné mohou infikovat DLL knihovny omylem, protože mají interní strukturu PE (nebo NE) souboru. Další infekce z takových souborů nemusí být funkční, protože systémový zavaděč nevolá standardní vstupní bod DLL knihovny, ale specifický vstupní bod pro DLL. Infektory KERNEL32.DLL neútočí na standardní vstupní bod programu a snaží se získat řízení jiným způsobem. PE soubory mají mnoho jiných vstupních bodů, které mohou viry zneužít, speciálně DLL knihovny, které přirozeně exportují různé API (a jejich vstupní body). Nejjednodušším způsobem infekce KERNEL32.DLL je tedy přepsání RVA exportovaného API (například GetFileAttributesA) tak, aby ukazovalo na virový kód umístěný na konci souboru. Například virus W95/Lorez20 používá tuto techniku. Takové viry se dovedou snadno stát "rezidentními" – systém načte infikovanou knihovnu během inicializační fáze a poté bude ke každému programu, který importuje API z KERNEL32.DLL připojen i virus. Virus se aktivuje kdykoliv, když aplikace volá API, na které je virus zavěšený.

Všechny systémové DLL knihovny obsahují v PE hlavičce přepočítaný kontrolní součet umístěný linkerem. Narozdíl od Windows 95, Windows NT tento kontrolní součet přepočítávají, než DLL načte. Pokud součet nesedí, systémový zavaděč se zastaví a zobrazí během bootování modrou obrazovku s chybovou hláškou. To ovšem neznamená, že takový virus nemůže být pro Windows NT implementován – je to o trošku málo těžší. Ačkoliv není algoritmus kontrolního součtu Microsoftem zdokumentován, existuje pro tyto účely API v knihovně IMAGEHLP.DLL, a to CheckSumMappedFile(), jenž po infekci virem umí vypočítat správný kontrolní součet. To ovšem zavaděči systému Windows NT nestačí a je potřeba udělat ještě několik malých kroků, nicméně je jasné, že viroví autoři jsou schopni takové problémy překonat. Antivirové skenery musí kontrolovat konzistenci KERNEL32.DLL přepočítáním součtu a porovnáním se záznamem v hlavičce, zejména tehdy, pokud je skener sám Win32 aplikací a pokud se připojuje k infikované knihovně KERNEL32.DLL.

Počítačové viry – analýza útoku a obrana

165

4.3.2.6 Doprovodné (companion) viry Doprovodné viry se příliš běžně nevyskytují, nicméně někteří autoři vyvíjeli takové viry i pro Windows 95. Aktivace těchto virů se odvíjí od faktu, že operační systémy preferují při spouštění soubory s příponou COM před EXE soubory (v případě, kdy se jména souborů liší pouze v příponě). Takové viry jednoduše vyhledají PE aplikace s příponou EXE, a napadený soubor (s virovým kódem) uloží pod stejným jménem do stejného adresáře, a změní jeho příponu na COM. Například virus W95/Spawn.4096 používá tuto techniku. Celá jeho funkčnost je implementována prostřednictvím volání API FindFirstFileA(), FindNextFileA() (pro vyhledání souborů), CopyFileA (pro zkopírování souboru s virem) a CreateProcessA() (pro spuštění hostitele).

4.3.2.7 Dělené dutinové viry Původně jsem předpokládal, že se tato technika infekce rozvine až později v budoucnu, nicméně virus W95/CIH stihl tuto techniku představit ještě před mou první lekcí o Win32 virech.

Mezi sekcemi většinou existuje prázdné místo, které linker obvykle vyplňuje nulami (nebo 0xCC). To proto, že sekce musí začínat na násobku souborového zarovnání, jak to popisuje položka PE hlavičky FileAlignment. Aktuální virtuální velikost každé sekce se obvykle liší od její reprezentace v souboru.

Obvykle bývá virtuální velikost menší – takové PE soubory generuje ve většině případů linker od Micorosoftu. Rozdíl mezi velikostí syrových dat v souboru a virtuální velikostí v paměti obvykle spočívá v aktuální oblasti zarovnání, která je vyplněná nulami a nenačítá se do paměti, jakmile se program mapuje do adresovacího prostoru.

Protože je standardní hodnota položky FileAlignment 512 bajtů (obvyklá velikost diskového sektoru), typická velikost prázdné oblasti bude menší než 512 bajtů. Když jsem prvně uvažoval nad tímto druhem infekce, myslel jsem si, že se žádný virus nevleze pod 512 bajtů, protože je to příliš málo místa pro průměrný PE infektor tohoto druhu. Nicméně o dvě minuty později jsem zjistil, že ani tento problém nezastaví autory virů. Jediné, co je zapotřebí udělat, je rozdělit virové tělo do více částí a do největšího množství dostupného zarovnání sekce. Zaváděcí kód pro tyto bloky může být velmi krátký, pouze přesunuje jeden blok virového kódu po druhém do alokované paměti, což mnoho místa nezabere.

Tuto precizní metodu používá virus W95/CIH a práci skenerů tím dost znesnadňuje. Virus změní virtuální velikost každé sekce tak, aby byla stejně velká jako nezpracovaná (raw) data v souboru a vloží tam své virové tělo. Přesná identifikace takových virů je složitější než u normálních virů, protože virové tělo musí být poskládáno z více různých částí PE souboru.

W95/CIH také používá metodu infekce hlavičky a bez problémů infikuje programy vytvořené linkerem od Microsoftu. Dělená dutinová technika infekce má z pohledu viru velmi důležitou výhodu: infikovaný soubor se po infekci nezvětší, jeho velikost zůstane stejná, což znesnadní zpozorování viru. Identifikace se musí provést velmi pečlivě, protože virus může svoje tělo rozdělit na libovolný offset, což může také vést k nutnosti rozdělit vyhledávající řetězec na více částí. Proto je důležité analyzovat nové viry pro Windows 95 s extrémní opatrností, jinak skener nemusí být schopen detekovat všechny generace stejného viru.

166

Kapitola 4 – Klasifikace metod infekce

4.3.2.8 Modifikace položky lfanew ve staré EXE hlavičce Jedná se o druhou metodu infekce, kterou jsem chtěl popsat, ale o které jsem si myslel, že ještě nebyla vyvinuta. Ale stejně jako v případě techniky dělené dutinové infekce (byla popsána v předchozí části), se tato technika objevila během doby, co jsem o ni psal. Co se týče implementace, jedná se o jednu z jednodušších technik a je proto využívána v mnoha virech. Prvním takovým známým virem je W95/Cerebus, který by fungoval i na Windows NT, nebýt drobné chyby v jeho kódu. V podstatě se jedná o techniku připojení se na konec souboru.

Rozdíl spočívá v tom, že virus přidává do souboru vlastní PE hlavičku. Když virus infikuje PE aplikaci, změní ve staré EXE hlavičce položku lfanew (na adrese 0x3c). Jak již bylo popsáno dříve, položka lfanew obsahuje adresu PE hlavičky v souboru. Protože ukazuje na novou verzi PE hlavičky, spustí se program obsahující pouze virový kód a virus funguje jako normální Win32 aplikace. Má vlastní tabulku importů a dovede jednoduše volat libovolné API. Když je replikace u konce, virus vytvoří dočasný soubor s kopií infikovaného programu. V tomto souboru se bude položka lfanew odkazovat na původní PE hlavičku a původní program bude fungovat stejným způsobem jako předtím.

4.3.2.9 VxD viry pro Windows 95 Většina virů pro Windows 95 jsou infektory přímé akce. Autoři virů rozpoznali důležitost rychlé infekce a pokusili se přijít s implementací rezidentních virů pro Windows 95. Logickým, avšak nikoliv jednoduchým, řešením bylo napsání VxD viru. Jedním z prvních VxD virů byl W95/Memorial, který infikoval DOSové COM, EXE a PE aplikace. Virus se nešířil bez Windows 95 a infikované programy vypouštěly původní virový kód – VxD do kořenového adresáře disku C: jako CLINT.VXD. Jakmile se VxD nahraje do paměti, spustí se virový kód v okruhu oprávnění 0 (ring 0) a virus může dělat cokoliv, co se mu zamane. VxD moduly se dovedou zavěsit na souborový systém, což je přesně to, co viry zajímá. Jednoduchou obslužnou VxD rutinu se zavěsí na instalovatelný souborový systém (IFS, Installable File Systém). Pak už virus dokáže monitorovat přístup ke všem souborům. VxD kód se musí extrahovat na disk a kód vypouštěče vyžaduje rozdílné implementace pro jednotlivé souborové formáty, které virus infikuje. To činí kód viru velmi složitým a relativně velkým (12413 bajtů) a je velmi nepravděpodobné, že by se objevil další virus tohoto typu.

4.3.2.10 PE viry, které se chovají jako VxD S mnohem jednodušším řešením přišly viry W95/Harry a W95/Anxiety, které dovedou tyto nesnáze překonat přepsáním části VMM (Virtual Machine Manager) Windows 95 svým kódem.

Jakmile dojde ke spuštění infikovaného PE programu, virus převezme kontrolu. Programy jsou spouštěny na aplikační úrovni, což znamená, že nemohou normálně volat funkce na systémové úrovni (VxD volání). Tyto viry obchází systém instalováním svého kódu do VMM, který běží v okruhu oprávnění 0.

Instalační rutina viru hledá dostatečně velkou mezeru v oblasti kódu VMM za adresou 0xC0001000.

Pokud najde takovou oblast, která se skládá pouze z bajtů 0xFF, virus zkontroluje hlavičku VMM na adrese 0xC000157F a porovná ji s předpokládaným obsahem. Pokud data sedí, virus vezme adresu systémové funkce Schedule_VM_Event z VMM a uloží si ji pro pozdější použití, zkopíruje svůj kód do VMM přepsáním nalezené mezery svým kódem a změní adresu.

Počítačové viry – analýza útoku a obrana

167

Adresa Schedule_VM_Event pak ukazuje na novou funkci. Nakonec se spustí původní hostitelský program skokem na původní vstupní bod. Tohle vše je možné pouze proto, že Microsoft nemohl ochránit tuto oblast před nevhodnými změnami kvůli snaze o zachování kompatibility se starými VxD ovladači pro Windows 3.x. Aplikace tak mohou číst i zapisovat v celé oblast VMM. Než bude možné spustit původní hostitelský program, VMM zavolá Schedule_VM_Event, který virus nahradil svou inicializační rutinou. Kód se spustí v okruhu oprávnění 0, čímž je umožněno volat VxD funkce. Anxiety se zavěsí na IFS voláním funkce IFSMgr_InstallFileSystemApiHook, která virus sama zavěsí na souborový systém.

Replikační kód viru vyžaduje zvláštní obsluhu. Jakmile se zavolá VxD funkce, VMM kód volání přepíše z 0xCD, 0x20, DWORD <číslo funkce> (INT 20H, DWORD ID)21 na vzdálená (FAR) volání. Některé VxD funkce se skládají z jediné instrukce – v tomto případě VMM přepíše šestibajtový kód volání onou instrukcí (pokud se tam vleze). VMM toto dělá dynamicky se všemi spuštěnými VxD, aby zrychlil jejich vykonávání.

Jakmile je virový kód spuštěn, jsou přepsány volané VxD funkce v těle viru a virus se nemůže zkopírovat do souborů, protože by nefungoval v jiných prostředích Windows 95. Tyto viry obsahují funkce, které zpětně opraví jejich VxD volání do původního formátu, a teprve po jejich spuštění je kód připraven ke zkopírování se do hostitelského programu. Ačkoliv se to zdá poněkud komplikované, není to pro autory virů příliš obtížné. W95/Anxiety se rozšířil po mnoha zemích po celém světě.

Není pochyb o tom, že se některé viry pokusí překonat vzdálenost mezi okruhy 3 a 0 s použitím podobných technik i na systémech Windows NT. Virus W95/CIH používá instrukce, které jsou dostupné pouze od procesorů Intel 386 a výše. Tabulka descriptorů přerušení (IDT, Interrupt Descriptor Table) je ve Windows 95 dostupná i pro zápis, protože je součástí VMM. W95/CIH volá instrukcí SIDT (Store IDT) pro získání ukazatele na IDT (tato technika je podrobně popsána v kapitole 6). Tímto způsobem virus dovede změnit popisovač INT 3 (ladící přerušení, breakpoint) v IDT a alokovat paměť s pomocí služeb VxD. Potom se spustí INT 3, čímž se kód v PE hlavičce přepne do okruhu 0. Jedná se o jednoduchou metodu, jak překonat rozdíly mezi okruhy a dá se očekávat, že se v blízké době objeví viry, které přijdou s nějakou podobnou metodou, která může být ještě jednodušší.

4.3.2.11 Infekce VxD Několik málo virů, jako třeba Navrhar, infikují virtuální ovladače zařízení (VxDs, Virtual Device Drivers). Navrhar také infikuje dokumenty Wordu, které jsou uloženy v OLE2 formátu a některé standardní systémové VxD moduly. Virus neinfikuje neznámé VxD, ale pouze známé systémové, které jsou vypsány v PE vypouštěči viru. Jakmile se otevře dokument Wordu, virus vyextrahuje svůj PE vypouštěč, který je připojený na konec dokumentu. Jediným způsobem, jak zpřístupnit tento kód, je s použitím Win32 API a právě proto virus ve své makro části importuje knihovnu KERNEL32.DLL. Jakmile je kód vypuštěn z dokumentu, spustí se a pokusí se nainfikovat všechny VxD uvedené v seznamu. Až dojde k restartování systému, načte systém Windows 95 jeden z infikovaných VxD modulů do paměti. Virus získá řízení z infikovaných VxD, zavěsí se na souborový systém a počká si na přistoupení k nějakému dokumentu.

168

Kapitola 4 – Klasifikace metod infekce

Navrhar ilustruje, že narozdíl od souborů typu DOC se PE aplikace mezi uživateli příliš často nevyměňují – a to nezmiňuji na VxD, které se obvykle nevyměňují vůbec. To je také důvod, proč moderní viry pro Win32 místo toho používají nějakou formu mechanismu červí propagace (viz kapitoly 9 a 10).

4.3.2.12 Technika vkládání načítání DLL Tato technika je založená na tom, že se PE soubory změní tak, že po spuštění hostitele se do paměti natáhne i speciální DLL knihovna s virovým kódem.

Například virus W32/Initx načte pomocí volání LoadLibrary() vloženým do hostitelského programu DLL se jménem INITX.DAT. Tento speciální kód se vloží do prázdného místa v kódové sekci hostitele a vstupní bod se změní tak, aby ukazoval na vložený kód. Pokud je virová knihovna dostupná, po spuštění hostitele se aktivuje virový kód. Po skončení virus předá řízení zpět původnímu vstupnímu bodu hostitele.

4.3.3 Win32 a Win64 viry: navržené pro Microsoft Windows?

Strategie Microsoftu je jasná. Důležitým požadavkem k získání loga "Designed for Microsoft Windows" je, aby každá aplikace daného produktu byla Win32 programem zkompilovaným 32bitovým kompilátorem, který generuje spustitelný soubor ve formátu PE. Není překvapením, že počet Win32 programů vyvinutých třetími stranami během několika posledních let intenzivně vzrostl. Lidé si vyměňují a stahují stále více a více PE programů.

Hlavním důvodem, proč viry pro Windows 95 a Win32 dlouho nepůsobily žádné větší problémy, bylo především to, že autoři virů se museli naučit pracovat s novými systémy. Mladí autoři dobře rozumí heslu Microsoftu: "Všude Windows!", které jim osobně spíše zní jako "Všude viry pro Windows!" Tito mladí kluci už neztrácejí čas s DOSovými viry a místo toho se snaží zkoumat Win32 a Win64 platformy.

Neexistuje už žádný důvod, proč psát viry pro DOS. Virové skenery jsou mnohem slabší jak při obecném, tak i při heuristickém zpracování virů pro Windows – detekce a dezinfekce už nejsou tak jednoduché. Dodavatelé se musí naučit rozumět novému 64bitovému souborovému formátu a musí strávit odpovídající množství času na zkoumání a navrhování nových skenovacích technik.

Protože jsou systémy Windows 95 a Windows NT komplikovanější, je přirozené, že první viry potřebovaly více času na naprogramování než poslední viry pro DOS. I přes tyto komplikace dosáhl v roce 2004 počet virů pro Win32 celkového čísla 10 000. DOSovým virů trvalo asi 10 let, než bylo dosaženo takového počtu, platformě Win32 stačilo o rok míň. To naznačuje, že ačkoliv se psaní virů zpomaluje s tím, jak na svět přicházejí nové platformy (které nahrazují ty staré), šířící potenciál jakéhokoliv viru bude exponenciální.

V následující části popíšu některé důležité prvky, které činí Windows 95 viry nekompatibilními s Windows NT. To zahrnuje rozdíly mezi prefixy Windows 95 a Win32, které jsou používány skenery k identifikaci 32bitových virů pro Windows.

Počítačové viry – analýza útoku a obrana

169

4.3.3.1 Důležité rozdíly v systémovém zavaděči na Windows 95 a NT Než jsem narazil na virus W32/Cabanas, měl jsem odlišný obrázek o platformě Windows NT z hlediska bezpečnosti, protože jsem udělal nesprávné závěry o úrovni systémové bezpečnosti v době, když se objevil virus Boza pro Windows 95. Většina antivirových výzkumníků okamžitě provedla s Bozou testy na Windows NT. Výsledek nás ujistil o jednom – Windows NT se nepokusí infikovaný soubor ani spustit, jak je vidět na obrázku 4.30.

Obrázek 4.30

Zobrazená chybová hláška při spouštění W95/Boza na Windows NT.

Co je dobré pro zavaděč systému Windows 95, to se nelíbí Windows NT. Proč? Na tuto otázku jsem si odpověděl úpravou PE souborů.

Souborový formát PE byl navržen Microsoftem pro použití ve všech operačních systémech podporující Win32 (Windows NT/2000/XP/2003, Windows 95/98/ME, Win32s a Windows CE). Později byl rozšířen na PE+ kvůli podpoře 64bitových platforem. Proto musí všechny systémové zavaděče ve Win32 prostředích rozumět této spustitelné struktuře. Implementace zavaděče se nicméně liší ze systému na systém. Zavaděč systému Windows NT oproti Windows 95 jednoduše kontroluje více záznamů v PE souboru, než se jej pokusí spustit. Proto Windows NT nedovolí spuštění souboru infikovaného virem Boza – jedna položka v hlavičce sekce .vlad (vepsaná do hlavičky) není správně spočítána. Pokud je sekce spočítána správně, nic nebrání upravenému PE souboru v jeho spuštění. Zavaděč systému Windows NT tedy nemá nějakou ochranu proti virům, jak by si někdo mohl myslet.

Pokud by autoři viru tento problém opravili, virus by byl schopen spustit původní hostitelský program i na platformě Windows NT, ačkoliv by nebyl schopný se na tomto systému replikovat. To zase kvůli jinému problému s kompatibilitou, který měly všechny počáteční viry pro Windows 95. Každý takový virus musí překonat jeden problém: musí být schopný volat dvě API Win32, a to GetModuleHandle() a GetProcAddress(). Protože jsou tato API v KERNEL32.DLL, viry k nim přistupovaly přímo, a to přes pevné adresy. Použitím funkce GetProcAddress() může virus získat adresy všech API, které si zamane (některé viry používají k získání adresy KERNEL32.DLL volání LoadLibrary(), nicméně tato metoda není příliš běžná, protože většina aplikací mapuje KERNEL32.DLL do svého adresovacího prostoru).

Když linker sestavuje spustitelný soubor, předpokládá, že bude soubor namapován na specifické místo v paměti. V PE hlavičce je položka ImageBase, která obsahuje tuto adresu. Pro spustitelné soubory to většinou bývá adresa 0x400000, v případě knihovny KERNEL32.DLL pod Windows 95 je tato adresa 0xBFF70000. Adresa GetModuleHandle() a GetProcAddress() bude také na podobném místě (v případě stejné verze Windows 95). Tyto adresy se ovšem mohou měnit od jedné verze Windows 95 k druhé, čímž vzniká ona nekompatibilita. Ve Windows NT bývá hodnota ImageBase knihovny 0x77F00000 a proto viry pro Windows 95, které pracují s pevnými adresami, nejsou schopny fungovat v prostředí Windows NT.

170

Kapitola 4 – Klasifikace metod infekce

Třetí důvod nekompatibility je také zřejmý: Windows NT nepodporují VxD (například virus Memorial nemůže pod Windows NT správně fungovat, protože je založen na využívání VxD). Bylo by tak nutné naprogramovat dva odlišné algoritmy infekce na úrovni ovladačů pro Windows NT a pro Windows 95, což práci docela komplikuje.

Pokud virus pro Windows 95 dovede překonat předchozí problémy s kompatibilitou a implementací, bude eventuálně schopný fungovat i v prostředích Windows NT/2000/XP/2003. Takové viry mohou mít podporu unicode, ale není to nezbytné. W32/Cabanas podporuje všechny tyto vymoženosti a dovede přeskočit hranici, která je jiným výtvorům pro Windows 95 uzavřená.

Jak Boza, tak i Cabanas jsou 32bitové programy pro Win32. Cabanas infikuje nejenom soubory běžící pod Windows 95/98/ME (a libovolné lokalizované verze), ale také soubory běžící pod všemi hlavními systémy, které jsou založené na technologii Windows NT (3.51, 4.0, 5.0 – Windows 2000 a 5.1 – Windows XP). Oproti tomu se virus Boza se umí replikovat pouze pod anglickými Windows 95. Proto má Cabanas prefix Win32 a Boza Win95.

4.4 Závěr Tato kapitola vám ukázala vše podstatné, co se odehrává za technikami infekce souborů a dalších systémových objektů. Je důležité si tyto techniky ozřejmit, protože mají velký dopad na návrh antivirových enginů a také ovlivňují metody jak ruční, tak i automatické analýzy, které jsou rozebrány v kapitole 15.

Odkazy 1. Adam Petho, ROM BIOS, 1989, ISBN: 963-553-129-X. 2. Fridrik Skulason, "Azusa-Complicating the Recovery Process", Virus Bulletin, duben 1991, str. 23.

3. Jakub Kaminski, "Rainbow: To Envy or to Hate", Virus Bulletin, září 1995, str. 2-7.

4. Mike Lambert, "Circular Extended Partitions: Round and Round with DOS", Virus Bull tin, září 1995, str. 14.

5. Fridrik Skulason, "Investigation: The Search for Den Zuk," Virus Bulletin, 1991, str. 6-7.

6. Mikko Hypponen, "Virus Activation Routines", EICAR, 1995, str. T3 1-11.

7. Fridrik Skulason, "Disk Killer", Virus Bulletin, leden 1990, str. 12-13.

8. Jan Hruska, "Virus Writers and Distributors", Virus Bulletin, červenec 1990, str. 12-14.

9. Dr. Vesselin Bontchev, soukromá komunikace, 1996.

10. Peter Morley, osobní komunikace, 1999.

11. Peter Szor, "Coping with Cabanas",Virus Bulletin, listopad 1997, str. 10-12.

12. Peter Szor, "Olivia", Virus Bulletin, červen 1997, str. 11-12.

13. Peter Szor, "Nexiv_Der: Tracing the Vixen", Virus Bulletin, duben 1996, str. 11-12.

14. Peter Szor, "Shelling Out", Virus Bulletin, February 1997, str. 6-7.

Počítačové viry – analýza útoku a obrana 15. Matt Pietrek, Windows Internals, Addison-Wesley, 1993, ISBN: 0-201-62217-3.

16. Adrian Marinescu, "Russian Doll", Virus Bulletin, srpen 2003, str. 7-9.

17. Peter Ferrie, "Unexpected Resutls [sic]", Virus Bulletin, červen 2002, str. 4-5.

18. Peter Szor, "Attacks on Win32", Virus Bulletin Conference, 1998.

19. Peter Szor, "High Anxiety", Virus Bulletin, leden 1998, str. 7-8.

20. Peter Szor, "Breaking the Lorez", Virus Bulletin, říjen 1998, str. 11-13.

21. Andrew Schulman, Unauthorized Windows 95, IDG Books, 1994, ISBN: 1-568-84305-4.

171

172

Kapitola 4 â&#x20AC;&#x201C; Klasifikace metod infekce

KAPITOLA 5 Klasifikace metod infekce paměti "Krůček po krůčku dojdeš nejdál."

– J.R.R. Tolkien

174

Kapitola 5 – Klasifikace metod infekce paměti

V této kapitole se dozvíte o běžných rezidentních paměťových technikách, které používají viry pro infekci dalších objektů v systému nebo napříč více systémy. V závislosti na použité strategii mohou být některé viry úspěšnější než jiné.

5.1 Viry přímé akce Některé jednodušší viry se aktivně neinstalují do počítačové paměti – do této kategorie patří první souborové infektory pro IBM PC, jako třeba Virdem a Vienna. Viry přímé akce se obvykle příliš nešíří a nesnadno se dostávají do světa.

Viry přímé akce se načtou do paměti během zavádění hostitele a po předání řízení vyhledají objekty k napadnutí. To je přesně ten důvod, proč je většina počítačových virů právě infektory přímé akce – takové viry je snadné vytvořit na mnoha platformách, v binárních i skriptovacích jazycích.

Tyto viry obvykle používají k nalezení svých obětí sekvence FindFirst a FindNext a infikují po svém spuštění pouze několik souborů. Některé viry ovšem infikují všechny dostupné oběti. V jiných případech se ihned zkopírují na disketu nebo pevný disk a nečekají, až to provede uživatel. Tato operace je nicméně snadno postřehnutelná, protože práce s disketou je docela hlučná.

V závislosti na umístění hostitele může být virus úspěšnější v síťovém prostředí. Na síti si může virus nechat vypsat všechny sdílené prostředky nebo na ně rovnou okamžitě zaútočit, za předpokladu, že jsou dostupné všechny síťové disky od A: do Z:. V tomto konkrétním případě mohou být viry přímé akce velmi pomalými infektory (dokud se neobjeví v síťovém prostředí).

Tisíce počítačových virů vytvořených nějakým generátorem používá tuto metodu v DOSu. Příkladem může sloužit virus VCL.428, vytvořený programem Virus Construction Laboratory.

5.2 Paměťově rezidentní viry Mnohem úspěšnější skupina počítačových virů zůstává po své inicializaci v paměti. Takové viry obvykle postupují v těchto krocích: 1. Virus získá řízení.

2. Vyhradí blok paměti pro svůj vlastní kód.

3. Přemístí svůj kód do vyhrazeného bloku.

4. Aktivuje se ve vyhrazeném bloku.

5. Zavěsí někam svůj kód.

6. Infikuje nové soubory, popř. systémové oblasti.

Toto je nejčastější způsob, ale pochopitelně existují i další metody, které se řídí podle jiného algoritmu.

Na jedno-úlohových operačních systémech (jako třeba DOS) může v jednom okamžiku běžet pouze jedna aplikace, ostatní programy se musí učinit TSR (Terminate and Stay Resident, ukončit se, avšak zůstat rezidentní), k čemuž DOS nabízí mnoho služeb ve formě přerušení.

Počítačové viry – analýza útoku a obrana

175

Typickým příkladem DOSového TSR programu je aplikace hodiny, která zobrazuje čas na obrazovce během spouštění programu. Protože všechny aplikace sdílejí jeden vykonávaný "thread", libovolný program může zasahovat do jiného programu, a to více způsoby. Dokonce i kód DOSu, systémové struktury, ovladače zařízení nebo rozhraní může změnit jedna chybná aplikace, což může vést k pádům systému a následnému poškození dat.

Na toto téma existuje jedna krátká anekdota. První verze tabulkového procesoru Borland Quattro pro DOS byla stoprocentně vyvinuta v assembleru v Maďarsku. Během vývoje došlo k zajímavé situaci: během vykonávání smyčky se občas tok řízení přesunul na opačnou stranu, než se očekávalo, přičemž z kódu nebylo patrné proč. Bylo to díky tomu, že běžící program hodin občas překlopil směr vykonávání modifikací příznaku směru (direction flag), a v některých případech jej zapomněl vrátit zpět.

Výsledkem bylo to, že špatně vytvořený program na zobrazování hodin mohl jednoduše poškodit obsah tabulkového procesoru nebo jiných programů. Chybný program byl samozřejmě TSR. Problém je v tom, že DOSové aplikace nejsou nijak separovány od ostatních a toho mohou jednoduše zneužít různé škodlivé programy. Ve standardním DOSu se procesor využívá v základním režimu, a proto mají všechny programy oprávnění modifikovat kód jiných programů umístěných ve fyzické paměti, která je adresovatelná až do 1 MB (některé počítače jsou schopny adresovat ještě nejvyšší 64 kB segment, tzv. HMA – High Memory Area).

5.2.1 Obsluha a zavěšování na přerušení DOSové programy používají jako systémové služby přerušení DOSu a BIOSu. V minulosti obvykle programátoři volali na mikropočítačích konkrétní vstupní bod BIOSu a museli tedy implementovat svou vlastní tabulku pevných adres. Tabulka vektorů přerušení (IVT, Interrupt Vector Table) tuto činnost programátorům IBM PC podstatně ulehčuje. S použitím IVT se programy odkazují na funkce příslušným číslem přerušení a číslem služby. Výsledkem je, že se programy obejdou bez nutnosti pamatovat si pevné adresy služeb, které volají a místo toho použijí instrukci INT x, která už sama předá řízení obsluze přerušení skrz IVT. Následující obrázek 5.1 znázorňuje typický boot virus (například Brain), který se instaluje do paměti zavěšením se na obsluhu disku BIOSu.

176

Obrázek 5.1

Kapitola 5 – Klasifikace metod infekce paměti

Typický boot virus zavěšený na INT 13h.

Boot viry se obvykle zavěšují na obsluhu přerušení INT 13h BIOSu, monitorují jeho funkce a čekají na práci s disketou (čtení nebo zápis dat) a během takové operace zapíšou do boot sektoru svůj kód.

V DOSu je IVT umístěna na začátku fyzické paměti na adrese 0:0. Tato tabulka udržuje pro každé přerušení segment a offset příslušné obsluhy, takže každá položka v tabulce zabírá 4 bajty. Vektor přerušení INT 21h tedy můžeme nalézt na adrese 0:84h. Tabulka 5.1 znázorňuje obvyklá přerušení a jejich typické použití počítačovými viry.

Počítačové viry – analýza útoku a obrana

177

Tabulka 5.1 – Typická přerušení používaná počítačovými viry INT ID

Funkce

IVT

Činnost počítačového viru

INT 00

Chyba při dělení Generováno CPU

0:[0]

Obrana proti ladění a emulaci

INT 01

Trasování Generováno CPU

0:[4]

Obrana proti ladění, tunelování, EPO

INT 03

Breakpoint Generováno CPU

0:[0Ch]

Obrana proti ladění, trasování

INT 04

Přetečení Generováno CPU

0:[10h]

Obrana proti ladění a emulaci (pomocí instrukce INTO)

INT 05

Tisk obrazovky BIOS

0:[14h]

Aktivační rutina, obrana proti ladění

INT 06

Neplatný operační kód Generováno CPU

0:[18h]

Obrana proti ladění a emulaci

INT 08

Systémový časovač Generováno CPU

0:[20h]

Aktivační rutina, obrana proti ladění

INT 09

Klávesnice BIOS

0:[24h]

Obrana proti ladění, krádež hesel, obsluha Ctrl+Alt+Del

INT 0Dh

IRQ 5 – HD Disk (XT) Hardware

0:[34h]

Stealth na hardwarové úrovni na XT

INT 10h

Video BIOS

0:[40h]

Aktivační rutina

INT 12h

Velikost paměti BIOS

0:[48h]

Kontrola velikosti RAM

INT 13h

Disk BIOS

0:[4Ch]

Infekce, aktivační rutina, stealth

INT 19h

Zavaděč BIOS

0:[64h]

Falešný reboot

INT 1Ah

Čas

0:[68h]

Aktivační rutina

INT 1Ch

Systémový časovač BIOS

0:[70h]

Aktivační rutina

INT 20h

Ukonči program DOS Kernel

0:[80h]

Infekce při ukončení, ukončení rodiče

INT 21h

Služba DOSu DOS Kernel

0:[84h]

Infekce, stealth, aktivační rutina

178

Kapitola 5 – Klasifikace metod infekce paměti

INT ID

Funkce

IVT

Činnost počítačového viru

INT 23h

Obsluha Ctrl+Break DOS Kernel

0:[8Ch]

Obrana proti ladění, nepřerušitelná infekce.

INT 24h

Obsluha kritických chyb DOS Kernel (obvykle jen dočasně)

0:[90h]

Zrušení chybových hlášek během infekce.

INT 25h

DOS – Absolutní čtení z disku (DOS Kernel) (Nakonec volá INT 13h)

0:[94h]

Infekce disku, stealth.

INT 26h

DOS – Absolutní zápis na disk (Nakonec volá INT 13h)

0:[98h]

Infekce disku, stealth (DOS Kernel).

INT 27h

Terminate-and-Stay Resident (DOS Kernel)

0:[9Ch]

Ukončení a ponechání v paměti (DOS Kernel).

INT 28h

Přerušení DOS IDLE DOS Kernel

0:[A0h]

Vykonání TSR, zatímco DOSový program čeká na uživatelský vstup.

INT 2Ah

Síťový směrovač DOS Kernel

0:[A8h]

Infekce souborů bez zavěšení na INT 21h

INT 2Fh

Multiplexní přerušení (Vícero použití)

0:[BCh]

Infekce paměti HMA, přístup k diskovým strukturám.

INT 40h

Obsluha diskety BIOS

0:[100h]

Blokování monitoru chování

INT 76h

Operace IRQ 14 HD Hardware

0:[1D8h]

Stealth na hardwarové úrovni na AT a výše.

Rodina procesorů x86 dovede v IVT uložit až 256 různých přerušení. Informace o přerušeních (a nejen o těch vypsaných výše) jsou dostupné v seznamu přerušení od Ralfa Browna (Ralf Brown Interrupt List), který obsahuje cca 3000 stránek plných podrobných informací. Původně bylo množství dostupných informací o přerušeních minimální, ovšem během pár let se Interrupt List stal pro všechny (anti)virové výzkumníky hlavním zdrojem dokumentovaných i nedokumentovaných informací.

Technika rezidentních virů má oproti virům přímé akce mnoho výhod. Takové viry umí snadno infikovat nové objekty za běhu, kdykoliv se k nim přistoupí. Dále se tyto viry umí maskovat s použitím stealth technik.

Ve východních zemích, jako třeba v Bulharsku, se takové informace (v době před rozšířením Internetu) velmi těžce sháněly. Programátoři v takových zemích byli vlastně odkázáni na reverzní inženýrství DOSu, pokud chtěli získat takové informace. Mnoho vylepšených virů z Bulharska používalo funkce

Počítačové viry – analýza útoku a obrana

179

interního volání DOSu 2+ nazývané jako "Get List of Lists" (INT 21h-AH=52h) pro účely tunelování, což nejednou přivedlo virové výzkumníky do rozpaků.

5.2.2 Závěsné rutiny na INT 13h (boot viry) Přerušení se obvykle volá se sadou registrů, které definují požadovanou subfunkci a ukazatele na datové struktury. Například – INT 13h přijímá číslo subfunkce v registru AH. Pro čtení z disku je potřeba vyplnit tyto registry: 

AH – 2



AL – Počet sektorů ke čtení



CH – Cylindr



CL – Sektor



DH – Číslo hlavy



DL – Číslo disku



ES:BX – Ukazatel na vyhrazený (alokovaný) datový buffer

Paměť musí být už před voláním přerušení alokována a disk je potřeba nejprve vyresetovat. Je známou skutečnosti, že diskety jsou příliš pomalé, neotáčejí se dostatečně rychle a potřebují pár čtení navíc včetně resetů mezi nimi. Je dobré vědět, že pevné disky začínají číslem 80h (nastavený bit 7).

Jakmile je voláno přerušení, návratová adresa je uložena na zásobník. Když volaná obsluha přerušení (nebo zřetězené obsluhy) vrátí instrukcí IRET, použije návratovou hodnotu ze zásobníku. Obsluha přerušení může také skončit instrukcí RETF. Boot viry se přirozeně zajímají o hodnoty AH registru předávané při volání INT 13h. Vložením nové obsluhy do IVT dovede virus jednoduše monitorovat tuto hodnotu několika instrukcemi porovnání (CMP) a na základě toho provádět příslušnou činnost.

Typické boot viry po svém spuštění ukládají původní obsluhu INT 13h: MOV

AX,[004C] ; Offset INT 13h

MOV

[7C09],AX ; Ulož pro pozdější použití

MOV

AX,[004E] ; Segment INT 13h

MOV

[7C0B],AX ; Ulož pro pozdější použití

Boot viry alokují paměť těsně před jejím koncem na 640 kB hranici manipulací s daty BIOSu na segmentu 40h, a to změnou slova na adrese 40h:13h (0:[413h]), které popisuje velikost paměti. Změnou této hodnoty se žádnému programu nepodaří alokovat paměť nad tímto nově nastaveným limitem – obvykle se jedná o pár kilobajtů méně před původním nastavením.

Virus pak zkopíruje svůj kód do takto "alokovaného" bloku paměti a zavěsí se na obsluhu INT 13h. Je zajímavé, že se některé viry, jako třeba Stoned, se zavěšují na INT 13h ještě před tím, než přemístí svůj kód do paměti. Virus spoléhá na to, že během bootování nedojde k žádnému dalšímu čtení z disku, takže kód nezhavaruje.

Kapitola 5 – Klasifikace metod infekce paměti

180

Zavěšení se na obsluhu je stejně jednoduché, jako je třeba zápis do IVT. MOV

[004C],AX

; Nastav nový offset INT 13h v IVT

MOV

[004E],ES

; Nastav nový segment INT 13h v IVT

Nová obsluha (handler) viru Stoned je ukázaná ve výpisu 5.1.

Výpis 5.1 Nová obsluha instalovaná virem Stoned.

PUSH

DS

; Ulož DS na zásobník

PUSH

AX

; Ulož AX na zásobník

CMP

AH,02

; Čtení z disku?

JB

Exit

; Skoč na Exit, pokud je menší

CMP

AH,04

; Verifikace?

JNB

Exit

; Skoč na Exit, pokud není čtení/zápis

OR

DL,DL

; Disketa A: ?

JNZ

Exit

; Skoč na Exit, pokud ne

XOR

AX,AX

; Nastav AX=0

MOV

DS,AX

; Nastav DS=0

MOV

AL,[043F]

; Přečti stav motoru diskety

TEST

AL,01

; Běží motor na disku A:?

JNZ

Exit

; Skoč na Exit, pokud ne

CALL

Infect

; Pokus se o infekci

POP

AX

; Obnov AX ze zásobníku

POP

DS

; Obnov DS ze zásobníku

FAR [0009]

; Skoč na předchozí uloženou obsluhu

Exit:

CS: JMP

Bylo by patrně neetické zde zveřejňovat více virového kódu, ale předchozí krátký úryvek by vám měl dát představu o tom, jak vypadá v praxi zavěšování se na obsluhu přerušení. Je z něj také vidět, jak vypadá virus z pohledu antivirového výzkumníka. V minulosti jsme například komentovali kód na vytištěném papíře, pěkně řádek po řádku. Někdy bylo papíru příliš mnoho a analýza kódu pak vypadala jako turnaj v běhu na sto metrů. Naštěstí se objevily výborné nástroje na analýzu, jakým je třeba IDA (Interactive DisAssembler). Ohledně těchto nástrojů je uvedeno více v kapitole 15.

5.2.3 Závěsné rutiny na INT 21h (souborové viry) Souborové viry se obvykle zavěšují na přerušení DOSu INT 21h a často se tak děje prostřednictvím subfunkcí 35h a 25h (získej a nastav adresu vektoru přerušení). Ale ne všechny viry mění vektor INT 21h v ITV, příkladem viru, který to nedělá, je například Frodo, který byl vytvořen v Izraeli v roce 1989.

Frodo se nezavěšuje na vektor INT 21h normální metodou – místo toho modifikuje pravý vstupní bod INT 21h vložením instrukce skoku na jeho začátek, která se postará o skok na virovou obsluhu.

Počítačové viry – analýza útoku a obrana

181

Frodo je podle všeho jedním z prvních souborových virů, které pod systémem MS-DOS využívají úplné stealth techniky (virus od Dark Avengera, Number_Of_The_Beast1, rovněž používal úplnou stealth techniku, a to dokonce pár měsíců před Frodem, ale teprve Frodo učinil tuto techniku slavnou).

Odposloucháváním subfunkcí INT 21h dokáže Frodo zatajit změny před DOSovými programy, a to dokonce i tehdy, když čtou data ze souboru. Virus je natolik sofistikovaný, že dokáže podvrhnout původní nezavirovaný obsah souboru.

Pojďme se podívat na vektor INT 21h na systému DOS zavirovaném Frodem za použití programu DEBUG. C:\ >DEBUG (spustíme DEBUG)

Vypíšeme si vektor INT 21h, který obsahuje hodnotu 19:40EB (segment:offset v paměti). I pro zrak zkušeného oka tato hodnota nepředstavuje nic podezřelého, vypadá vcelku normálně. To proto, že paměť je obvykle zaplňována z nižších segmentů směrem k vyšším, a tak segment 19 může být v samotném DOSu nebo i před ním, právě proto, že ukazuje do nižšího paměťového segmentu.

-d 0:84 l4 0000:0080

EB 40 19 00

.@..

A dále se podíváme na obsluhu, která je na nalezené adrese, s použitím příkazu "unassembly" (viz následující výpis 5.2).

Výpis 5.2 Instrukce skoku (JMP) směřující na Frodovu závěsnou rutinu.

-u19:40eb 0019:40EB EAD502209E

JMP

9E20:02D5

; Skoč na VIRSEG:02d5

0019:40F0 D280FC33

ROL

BYTE PTR [BX+SI+33FC],CL

0019:40F4 7218

JB

410E

0019:40F6 74A2

JZ

409A

0019:40F8 80FC64

CMP

AH,64

0019:40FB 7711

JA

410E

0019:40FD 74B5

JZ

40B4

0019:40FF 80FC51

CMP

AH,51

0019:4102 74A4

JZ

40A8

Předchozí kód vypadá trošku divně – ačkoliv můžeme vidět obvyklé instrukce porovnání (CMP), instrukce skoku ve vstupním bodě předává řízení adrese 9E20:02D5 – tento kód je přepsán samotným virem.

A konečně se můžeme podívat na kus kódu, který se nachází ve Frodově vstupním bodě. Dalším příkazem k disassemblování odhalíme virový kód umístěný v paměti, jak je vidět na výpisu 5.3.

182

Kapitola 5 – Klasifikace metod infekce paměti

Výpis 5.3 Začátek Frodovy závěsné rutiny.

-u9e20:02d5 9E20:02D5 55

PUSH

9E20:02D6 8BEC MOV

BP

; Ulož BP

BP,SP

; BP = SP

BX

; Ulož BX

: : 9E20:02F3 53

PUSH

9E20:02F4 BB9002 9E20:02F7 2E

MOV

9E20:02F8 3A27 CMP

AH,[BX]

9E20:02FA 7509 JNZ

0305

9E20:02FC 2E

BX,0290

; BX = tabulka funkcí

CS: ; Je tato zavěšená? ; Zkontroluj všechny položky

CS:

; Najdi shodu

9E20:02FD 8B5F01

MOV

BX,[BX+01]

; offset závěsné rutiny

9E20:0300 875EEC

XCHG

BX,[BP-14]

; Nastav návratovou adresu

9E20:0305 83C303

ADD

BX,+03

; Přejdi na další položku

9E20:0308 81FBCC02

CMP

BX,02CC

; Jsme na konci?

9E20:030C 72E9 JB

02F7

9E20:0303 FC

CLD

9E20:0304 C3

RET

; Spusť závěsnou rutinu

; Pokud ne, porovnávej dál

Frodo je velmi šikovný – místo toho, aby použil klasickou větev "switch" s použitím instrukcí porovnání (CMP), používá tabulku na offsetu 290 virového segmentu a podle ní předává řízení subfunkcím INT 21h. Tučné znaky v následující tabulce jsou DOSové subfunkce, následované offsetem, na kterém se nalézají příslušné obsluhy. Ukažme si nyní obsah paměti z virového segmentu :290.

-d9e20:290 9E20:0290

30 7C 07 23 4E 04 37 8B-0E 4B 8B 05 3C D5 04 3D

0|.#N.7..K..<..=

9E20:02A0

11 05 3E 55 05 0F 9B 03-14 CD 03 21 C1 03 27 BF

..>U.......!..’.

9E20:02B0

4E-9F 04 4F 9F 04 3F A5 0A 03 11 59 03 12 59 03 4E

..Y..Y.N..O..?..

9E20:02C0

40 8A 0B 42 90 0A 57 41-0A 48 34 0E 3D 00 4B 75

@..B..WA.H4.=.Ku

Poznámka Předchozí funkce jsou vypsány společně s jejich popisem v části věnovaném úplným stealth virům.

Souborové viry obvykle infikují programy odposloucháváním INT 21h, AH=4Bh (spuštění programu).

S touto události se z pohledu viru pracuje nejsnadněji. Souborové jméno je nabízeno na stříbrném podnose, protože se předává jako parametr funkce. Nejúspěšnější viry používají tento trik ke své replikaci, ale mnoho z nich navíc infikuje soubory během jejich otevírání a zavírání, což může viru s šířením výrazně pomoci. Například – antivirový skener otevře všechny objekty pro skenování, přičemž virus tato volání odposlechne a může s pomoci skeneru soubory okamžitě infikovat. Moderní antivirová řešení,

Počítačové viry – analýza útoku a obrana

183

jako třeba F-PROT, kontrolují velikost souboru dvěma způsoby, čímž omezují pravděpodobnost takového útoku – standardní funkcí "get file size" a posunem ukazatele souboru na jeho konec – výsledky se pak porovnají a pokud se neshodují, předpokládá se, že je systém napaden stealth virem. Úplné stealth techniky ovšem umí zatočit i s touto strategií, dokud je virus přítomen v paměti a jeho závěsné rutiny nejsou deaktivovány2.

Tabulka 5.2 ukazuje některé z prvních rozšířených virů společně se seznamem odchytávaných přerušení a typů infekce.

Tabulka 5.2 – Typické závěsné rutiny přerušení v prvních počítačových virech Jméno viru

Typ infekce

Odchytávaná přerušení

Brain

DBR, Stealth

INT 13h

Stoned

DBR, MBR

INT 13h

Cascade

COM, zakódovaný

INT 1Ch, INT 21h

Frodo

COM, EXE, Stealth

INT 1, INT 23h, INT 21h

Tequila

Multipartitní: EXE, MBR, oligomorfní, stealth

INT 13h, INT 1Ch, INT 21h

Yankee_Doodle

COM, EXE

INT 1, INT 1Ch, INT 21h

5.2.4 Obvyklé techniky instalace do paměti pod DOSem V této části se dozvíte o častých technikách počítačových virů, které používají pod operačním systémem DOS pro svoji vlastní instalaci do paměti. Protože DOS nemá žádnou ochranu paměti, viry mohou jednoduše měnit údaje v libovolné části paměti. Naštěstí pod DOSem nemají viry možnost se efektivně ukrýt v paměti, protože fyzická paměť je spojitá a virový kód může být jednoduše nalezen. To je důvodem, proč pro DOS neexistují viry se stealth technikou v paměti, ačkoliv existuje mnoho postupů, pomocí kterých se virus snaží nainstalovat do nezvyklých oblastí paměti pro zmatení antivirových programů, které klasicky vyhledávají vzorky virů u obsluh vektorů přerušení nebo v určité oblasti paměti (do 640KB, ale už ne nad tímto limitem). 

Nejjednodušší způsobem, jakým lze nainstalovat virus do paměti, je neotravovat se s paměťovou alokací. Tuto zřídkakdy používanou techniku například používá virus Stupid. Jednoduše se zkopíruje těsně pod 640 KB, ale už nezmenší položku popisující velikost paměti na adrese 0:[413h] a dále spoléhá na to, že tato oblast nikdy nebude přepsána jiným programem. Pokud k tomu dojde, systém zhavaruje.

Tato technika je příležitostně vylepšena o zkopírování virového kódu na konec paměti, přičemž se DOSu nedovolí alokovat bloky nad adresou viru, čímž se zabrání jeho nechtěnému přepsání.



Častou metodou je také nalezení nějaké díry v paměti, která je už sice alokovaná, ale zřídkakdy se používá. Taková mezera se nachází na několika místech v paměti DOSu, například druhá polovina IVT (nad 0:200h) se téměř nepoužívá, a proto se tam dá uložit krátký virový kód.

184

Kapitola 5 – Klasifikace metod infekce paměti Takové viry nebývají kompatibilní s rozšířeními DOSu a síťových shellů, které obývají vektory přerušení nad 0:200h. Kdykoliv je takový shell nainstalovaný, virus se zhroutí.

Jiné viry, jako třeba Darth_Vader (napsaný V.T. z Bulharska) sebe instalují do malé díry v DOSovém kernelu. Existuje pár dalších takových děr, které viry využívají pro svoje vložení. Pokud se tam ovšem už nachází něco jiného, virus není schopen se šířit dál.



Někdy, ovšem nepříliš často, DOSové viry používají k alokaci paměti TSR funkce, jako třeba INT 27h. Tuto metodu používá například virus Jerusalem.



Jednu z nejpoužívanějších technik představil boot virus Brain. Virus přečte slovo popisující vrchol paměti z adresy 0:[413h] a sníží 640 KB limit o několik KB, třeba na 639 KB, 638KB atd. a na tohle místo pak zkopíruje své tělo. Takové viry se dají velmi jednoduše vysledovat v paměti kontrolou vektorů přerušení, zda-li ukazují do horního segmentu paměti.

Boot viry tuto obvykle používají metodu. Příležitostně použijí INT 12h k získání vrcholu paměti a opět změní data BIOSu tak, aby se vrchol paměti snížil o nějakou malou hodnotu.



Další technika spočívá v manipulaci s interní strukturou DOSu MCB (Memory Control Block, řídící blok paměti). Takové viry obvykle zvětší nebo zmenší paměťové bloky a paraziticky se připojí do alokované paměti aplikace. Jiné viry jednoduše alokují nový MCB a nastaví jeho vlastníka na COMMAND.COM, což je příkazový interpret DOSu. Takový virus Cascade používá tuto techniku ke zmatení nástrojů sloužících pro vypsání paměťových bloků a aplikací, ke kterým patří.

Některé boot viry, jako třeba Filler, se zavěšují na INT 21h zejména z toho důvodu, aby ihned po natažení COMMAND.COM do paměti infikovaly jeho MCB.



Některé první viry pro DOS (například Lehigh) pro sebe alokují paměť v zásobníkové oblasti DOSu.



S šikovnou technikou přišly viry typu Starship. Tyto viry instalují svoji hlavní část mezi 640 KB a 1 MB (tzv. UMB, Upper Memory Blocks, vyšší bloky paměti) limit DOSu. Využívají volných oblastí v paměti UMB, jako třeba části video paměti, která není přiřazena žádné obrazovce.

Dalším příkladem viru, který se instaluje do oblasti UMB, je Tremor, napsaný v roce 1992.



Vylepšené viry také umí alokovat paměť pro svůj kód v HMA (High Memory Area, oblast vyšší paměti), která je dostupná, pokud je načten ovladač HIMEM.SYS. Jedná se o oblast paměti nad 1MB hranicí a je velká 64KB. Například virus GoldBug používá HMA na počítačích 286 a vyšších. Goldbug byl vyrvořen v USA v roce 1994 autorem Q the Misanthrope.

Velmi málo virů se instaluje do oblastí paměti, jako třeba XMS (Extended Memory Specification), ale některé viry to umí – třeba jedna varianta rodiny Ginger, kterou v roce 1995 napsali Roy g Biv a RT Fishel.



Neobvyklou techniku alokace paměti používá Reboot Panel (INT 2fh, AX=4A06h), aby donutil DOS k vytvoření MCB okolo kódu. Technika je používána3 viry vytvořenými autorem Q the Misanthrope.

Počítačové viry – analýza útoku a obrana

185

5.2.4.1 Techniky vlastní detekce v paměti Technika rozpoznání sebe sama v paměti je často založena na voláních typu "jsi tam?". Boot viry tuto techniku obvykle nepoužívají, protože se načítají pouze během bootování systému. Jiné viry infikující soubory se ovšem potřebují zavěsit na systém pouze jednou, takže se zavěsí na nějaké přerušení nebo souborový systém a vrátí specifický výstup pro speciální vstupní hodnoty registrů. Nově spuštěná kopie viru může zkontrolovat, zdali se už v paměti nenachází (voláním této rutiny). Paměťově rezidentní kopie odpoví na volání takto: "Ano, jsem tady, už se s instalací do paměti neobtěžuj". Tabulka 5.3 obsahuje některé příklady z DOSových systémů.

Tabulka 5.3 – Příklady volání "Jsi tam?" v prvních počítačových virech.

Jméno viru

Volání "Jsi tam?"

Návratové hodnoty

Jerusalem

INT 21h AH=E0h

AX=0300h

Flip

INT 21h AX=FE01h

AX=01Feh

Sunday

INT 21h AH=FFh

AX=0400h

Invader

INT 21h AX=4243h

AX=5678h

Nomenklatura

INT 21h AX=4BAAh

Příznak přenosu (Carry Flag) je vynulovaný

Na jiných systémech, jako třeba Windows, viry často používají "blokované semafory" (ram semaphores), jako třeba globální mutexy, které vytvoří během prvního spuštění. Takto se může nově načtená kopie jednoduše ukončit, pokud je už umístěna v paměti.

Viry pro Windows 95, které se zavěšují na souborový systém v režimu jádra, často používají podobná volání jako viry pro DOS. V některých případech se virus zavěsí na rutinu obsluhy I/O portu a vrací hodnoty na těchto virtuálních I/O portech. Třeba virus W95/SK získal svoje jméno právě díky této technice – zavěsí se na I/O port 0x534B (SK) a při čtení z tohoto portu vrací hodnotu 0x21 (!), jiné viry mohou na určitém místě zkoumat obsah paměti a kontrolovat existenci nějakého příznaku atd.

První antivirové programy používaly tato volání k detekci virů v paměti. Byly napsány specifické monitorovací programy, které simulovaly tato volání virů. Tohle řešení dokázalo virus zmást natolik, že si myslel, že už se v paměti nachází, a proto se do ní neinstaloval. Takové metody nicméně nejsou obecně příliš využitelné a používají je pouze jednoúčelové antiviry.

5.2.5 Stealth viry Stealth viry vždy odposlouchávají jednu nebo více funkci takovým způsobem, že ten, kdo danou funkci volá, obdrží od viru již upravená data. Antiviroví výzkumníci označují "stealth" takové viry, které jsou aktivní v paměti a neustále podvrhávají data, ke kterým přistupují jiné programy.

Autoři virů se neustále snaží soutěžit jak s uživateli, tak i s antivirovými výzkumníky a skenery. Některé techniky, jako třeba obrana proti heuristice a emulaci autoři virů vymysleli až v době, kdy začaly být skenery šikovnější. První stealth viry se nicméně objevily velmi brzo.

186

Kapitola 5 – Klasifikace metod infekce paměti

Ve skutečnosti už první ze známých virů na PC – Brain (boot virus) používal stealth techniky. Brain podvrhl původní boot sektor kdykoliv, když se přistoupilo k infikovanému boot sektoru, přičemž virus byl aktivní v paměti a odposlouchával přerušení disku. Byly to ty památné dny, kdy Alan Salomon (autor tehdejších rozšířených skenovacích programů) musel zjistit, co se to přesně děje se systémy infikovanými Brainem.

Stealth techniky se také rychle objevily v DOSových souborových virech. Jednalo se o jistý způsob, jak učinit virus nepostřehnutelným po relativně dlouhou dobu. V době DOSu si totiž uživatelé mohli pamatovat velikosti systémových souborů (jako třeba COMMAND.COM) a postřehnutí změny velikosti mohlo být prvním krokem k odhalení infekce.

V závislosti na tom, jak obtížné bylo takový virus odhalit a jaké metody používal, se viroví výzkumníci rozhodli vytvořit přesnější označení těchto technik. Následující části popisují nejznámější stealth techniky, tedy semi-stealth, stealth při čtení, úplné stealth a stealth na úrovni clusterů, sektorů a hardware.

5.2.5.1 Semi-stealth (adresářová stealth technika) Virus používající semi-stealth techniky utajuje velikost souboru, ale změny v obsahu infikovaných objektů už nikoliv – ty zůstávají při obyčejném přístupu na disk viditelné. První semi-stealth virus Eddie-2 byl vytvořen v bulharských továrnách na viry4 a postupoval podle následující strategie: 1. Virový kód se nainstaloval někam do paměti.

2. Potom se zavěsil na souborové funkce, jako třeba FindFirstFile nebo FindNextFile přes FCB. 3. Infikoval soubory konstantní délky (obvykle).

4. Označil infikovaný soubor nějakým příznakem.

5. Jakmile je odposlechnut přístup k infikovanému souboru, virus ve vrácených datech zmenšil jeho velikost na původní.

Protože takové viry potřebují rychle zjistit, zdali je soubor infikovaný nebo ne, je nejjednodušším způsobem použít speciální značku do časového/datového razítka souboru. Jedna z nejpopulárnějších metod byla prvně použita ve virech Vienna (ačkoliv byl tento virus infektorem přímé akce a tento trik tedy nepoužíval ve spojitosti se stealth technikami). Virus Vienna nastavoval druhou položku časového/datového razítka infikovaného souboru na "nemožnou" hodnotu 30 (což znamená 60 sekund) nebo na 31 (0 sekund). To proto, že toto razítko je v MS-DOSu uloženo jako 32bitová hodnota, kde nižších 5 bitů (0-4) uchovává sekundy v "komprimované" formě – sekundy jsou děleny dvěmi, takže uložená hodnota 2 znamená 4 sekundy, 29 znamená 58 atd., nicméně do 5 bitů se vleze jak 60, tak i 62 sekund, což mohou viry použít pro označení již infikovaných souborů.

Protože funkce FindFirstFile a FindNextFile vrací tuto informaci v datové struktuře, je tato značka dostupná kdykoliv, když závěsná funkce stealth viru zavolá původní funkci k získání příslušných dat o souboru – pro útočící virus tedy není velký problém zjistit, zdali je soubor už infikovaný nebo ne. Pokud je, změní se v datové struktuře záznam o velikosti souboru a tato pozměněná struktura se vrátí programu, který funkci volal.

Počítačové viry – analýza útoku a obrana

187

Semi-stealth techniky se v moderních operačních systémech (jako třeba v 32bitových Windows) příliš nepoužívají, avšak například první zdokumentovaný Win32 virus W32/Cabanas přišel s adresářovou stealth technikou i do tohoto prostředí.

5.2.5.1.1 Obsluha dispečeru VxDCall – INT21 S touto technikou přišel jako první W95/HPS5. Ten monitoruje volání funkcí LFN 714Eh/714Fh FindFirst/FindNext (Long File Name, funkce pracující s dlouhými jmény), které jsou pod Windows 95 z pohledu viru velmi zajímavé. Virus za chodu přepíše v zásobníku návratovou adresu funkcí FindFirst/ FindNext adresou své vlastní obsluhy. Ta zkontroluje, jestli je velikost programu dělitelná bezezbytku 101 a pokud ano, virus otevře program LFN funkcí, přečte velikost viru z posledních čtyř bajtů infikovaného programu, odečte tuto hodnotu od 32bitové proměnné původní návratové hodnoty FindFirst/ FindNext uložené na zásobníku a předá řízení zpět volajícímu podprogramu.

Tímto způsobem virus dovede skrývat změny ve velikostech souborů před většinou aplikací, ačkoliv virus neprodlužuje soubory o konstantní hodnotu.

5.2.5.1.2 Zavěšení na tabulku importovaných adres (IAT) S touto technikou přišel virus W32/Cabanas a je pravděpodobné, že ji také využijí novější Win32 viry, protože funguje na většině platforem Win32 s využitím stejného algoritmu. Závěsná funkce je založena na manipulaci s IAT. Protože má hostitelský program v sekci .idata uložené adresy všech importovaných API, všechno, co musí virus musí udělat, je nahradit tyto adresy adresami vlastních obsluh API volání.

Cabanas prvně vyhledá v IAT všechny možné jména funkcí, na které se umí zavěsit: GetProcAddress, GetFileAttributesA, GetFileAttributesW, MoveFileExA, MoveFileExW, _lopen, CopyFileA, CopyFileW, OpenFile, MoveFileA, MoveFileW, CreateProcessA, CreateProcessW, CreateFileA, CreateFileW, FindClose, FindFirstFileA, FindFirstFileW, FindNextFileA, FindNextFileW, SetFileAttributesA a SetFileAttributesW. Když nějakou takovou funkci v tabulce najde, uloží si její původní adresu do své tabulky skoků a v sekci .idata nahradí hodnotu DWORD (která obsahuje adresu API) ukazatelem na svou vlastní obsluhu.

Jak vypadají zavěšené API GetProcAddress() a FindFirstFileA() je vidět ve výpisu 5.4.

Výpis 5.4 Zavěšení na IAT. .text (CODE) 0041008E E85A370000

CALL 004137ED

00430068] 004137E7 FF2568004300 JMP [00430068 0043006C] 004137ED FF256C004300 JMP [0043006C 004137F3 FF2570004300 JMP [KERNEL32!ExitProcess] 004137F9 FF2574004300 JMP [KERNEL32!GetVersion] .idata (00430000) 00430068 830DFA77 ;-> 77FA0D83 Vstup do nové GetProcAddress

188

Kapitola 5 – Klasifikace metod infekce paměti

0043006C A10DFA77 ;-> 77FA0DA1 Vstup do nové FindFirstFileA 00430070 6995F177 ;-> 77F19569 Vstup do KERNEL32!ExitProcess 00430074 9C3CF177 ;-> 77F13C9C Vstup do KERNEL32!GetVersion NewJMPTable: 77FA0D83 B81E3CF177 MOV EAX,KERNEL32!GetProcAddress ; Původní 77FA0D88 E961F6FFFF JMP 77FA03EE ;-> Nová obsluha . .

77FA0DA1 B8DBC3F077 MOV EAX,KERNEL32!FindFirstFileA ; Původní 77FA0DA6 E9F3F6FFFF JMP 77FA049E ;-> Nová obsluha

Funkci GetProcAddress používá mnoho Win32 aplikací z toho důvodu, aby mohly volání API používat dynamicky, namísto tabulky adres importů, která je statická. Když hostitelská aplikace zavolá funkci GetProcAddress, aktivuje se nejprve původní funkce GetProcAddress k získání adresy požadované API. Potom zkontroluje, zdali se jedná o API z KERNEL32 a také to, zdali je to jedna z API, na kterou se chce virus zavěsit. Pokud to chce virus učinit, vrátí volajícímu adresu v tabulce NewJMPTable, čímž hostitel obdrží adresu virové obsluhy zavěšené na původní API. W32/Cabanas je adresářový stealth virus – během volání FindFirstFileA, FindFirstFileW, FindNextFileA a FindNextFileW virus zkontroluje, zda-li je program již infikovaný a pokud ne, virus jej napadne.

V opačném případě zamaskuje nárůst velikosti hostitele. Protože program cmd.exe (příkazový interpret Windows NT) používá během příkazu DIR předchozí API, každý neinfikovaný soubor bude v případě infikovaného cmd.exe tímto příkazem zavirován.

5.2.5.2 Stealth při čtení Stealth při čtení je vylepšená technika, která umí podvrhnout původní obsah infikovaného objektu, obvykle se tak činí odposloucháváním operací čtení a vyhledávání (seek).

První stealth viry, jako třeba Brain, tuto techniku používaly. Virus jednoduše odposlechl všechny přístupy na první sektor disket. Jakmile vznikl požadavek na přístup na tento první sektor a ten zatím nebyl infikován, virus jej zaviroval a uložil původní sektor na jiném místě na disketě. Jakmile se aplikace pokusila číst infikovaný DBR, virus přečetl původní uložený DBR sektor a vrátil jej volajícímu. Výsledkem bylo to, že programy, které se snažily přistoupit na boot sektor diskety, přečetly úplně jiný sektor. Pro názornost viz obrázek 5.2.

Počítačové viry – analýza útoku a obrana

Obrázek 5.2

189

Počítačový virus používající stealth techniky při čtení.

Stealth při čtení diskety je jednou z nejjednodušších metod. Autoři virů také implementovali stealth při čtení ve svých souborových injektorech pro DOS. Virus nepotřebuje mnoho – stačí mu odposlechnout souborové operace čtení a vyhledávání (seek) a vracet místo toho simulovaný obsah infikovaných souborů. Například viry připojující se na začátek programů mohou jednoduše odposlechnout všechny požadavky na otevření souboru, a jakmile se nějaká aplikace pokusí přečíst obsah infikovaného souboru, virus pouze přemístí souborový ukazatel tam, kde začíná původní souborová hlavička hostitele a volající aplikace bez problému dostane podvržený obsah.

5.2.5.3 Stealth při čtení v systémech Windows Možná se teď právě divíte, co se stalo s viry využívající techniky stealth při čtení na systémech Windows.

Znáte nějakého uživatele, který by si pamatoval velikost nějaké aplikace? Kdo by si toho všímal v době, kdy jsou aplikace tak velké, že se vůbec nevejdou na disketu? Vypadá to jako hlavní důvod toho, proč se objevilo pouze pár pokusů o naprogramování stealth virů na 32bitových systémech Windows. První stealth virus pro Windows 9x – W95/Sma6 – byl objeven v červnu 2002, zhruba 7 let po objevení prvního 32bitového viru pro Windows. Vývoj stealth technik evidentně nebyl na platformě Windows tak překotný jako v DOSu. Když jsem se prvně pokusil replikovat virus Sma na mém testovacím systému, bylo to jenom pár minut před tím, než jsem poznal, že se už nacházím "v Matrixu" ovládaném virem, a proto se mi jej nedařilo

190

Kapitola 5 – Klasifikace metod infekce paměti

namnožit. Nejprve jsem se domníval, že se virus zreplikoval, protože se na disku změnila velikost mých záchytných souborů. Tyto soubory jsem pak zkopíroval na disketu – a ejhle, zkopíroval jsem čisté soubory. Zopakoval jsem tuto proceduru celkem ještě dvakrát, než mi konečně došlo, že tu něco nehraje.

Použil jsem nástroj Windows Commander, abych se mohl podívat do souboru na infikované mašině.

Jistě – nic nového tam nepřibylo. Ve skutečnosti byl soubor větší, ale nic k němu nebylo připojeno. Potom jsem několikrát přistoupil i k souboru na disketě a náhle se velikost souboru změnila i tady. Vložil jsem tuto disketu do čistého systému a našel jsem tam W95/Sma. Hurá!

Virus se pokoušel nastavit druhou položku infikovaného PE souboru na 4, aby v takto označených souborech skryl velikost, nicméně v kódu viru byla zanesena chyba – virus při porovnávání značky vynuloval bit, takže později nebyl schopen značku najít – tudíž neukryl změnu ve velikosti souboru. Infikované soubory se zdají být větší o 4 kB, nicméně soubor má na svém konci připojeny akorát samé nuly.

Kdykoliv se otevře infikovaný PE soubor, který je navíc označen jako infikovaný, virus podvrhne obsah souboru – ukryje změny tak pečlivě, že je velmi obtížné najít jakoukoliv změnu. Virus tedy nahradí veškerý nový obsah souboru (například decryptor v mezeře mezi PE sekcemi) nulami a rekonstruuje původní obsah změněných hlaviček.

Takže – pokud by v kódu nebyla zmiňovaná chyba, virus by byl uchráněn před zvědavými zraky kohokoliv? Ano i ne. Virus zůstává skrytý při volání regulérních souborových funkcí _open() _read(), takže pokud někdo zkopíruje soubor prostřednictvím těchto funkcí, zkopíruje ho "čistý".

W95/Sma se nicméně nezavěšuje na operace mapování do paměti, takže sekvencemi API pro operaci s paměťově mapovanými soubory se dá tento virus jednoduše odhalit. Rozhodně se jedná o dobrou zprávu, bohužel většina antivirového software je z důvodu přenositelnosti napsaná s použitím regulérních céčkovských funkcí. Takové funkce nicméně virus umí monitorovat a on-demand skenery (skenery testující soubory na požádání) infikované soubory nepoznají.

Ještě zajímavější je payload viru W95/Sma. Virus čeká na spojení na UDP portu a jakmile přijde nějaký datagram, tak jej přijme a spustí v režimu jádra. To pak útočníkovi dovoluje, aby si dělal se systémem v podstatě cokoliv – třeba vzdáleně přepsat FLASH BIOS. V další části knihy se zaměříme na úplné stealth techniky pod DOSem.

5.2.5.4 Úplné stealth viry Rezidentní souborové infektory se obvykle zavěšují na některé funkce DOSu (v tabulce 5.4 je seznam zavěšovaných funkcí viru Frodo). Virus Frodo se zavěšuje na některé funkce, které vrací velikost nebo obsah souboru. Virus inkrementuje datum infikovaných souboru o 100 let, což je jeho vlastní značka pro napadené soubory.

Počítačové viry – analýza útoku a obrana

191

Tabulka 5.4 – Tabulka zavěšovaných funkcí úplného stealth viru Frodo.

Subfunkce v AH

Popis funkce

30h

Zjisti verzi DOSu

23h

Zjisti velikost souboru přes FCB (File Control Block)

37h

Zjisti/nastav příznak AVAILDEV

4Bh

Exec – Načti nebo spusť program

3Ch

Vytvoř nebo usekni soubor

3Dh

Otevři existující soubor

3Eh

Zavři existující soubor

0Fh

Otevři soubor přes FCB

14h

Sekvenční čtení přes FCB

21h

Náhodně přečti záznam přes FCB

27h

Náhodně blokově čti přes FCB

11h

Najdi první soubor přes FCB

12h

Najdi další soubor přes FCB

4Eh

Najdi první soubor

4Fh

Najdi další soubor

3Fh

Čti ze souboru

40h

Zapiš do souboru

42h

Posuň souborový ukazatel

57h

Zjisti časové/datové razítko

48h

Alokuj paměť

DOSový příkaz DIR ukazuje pouze zkrácený letopočet, jako třeba 1/09/89, takže se jednoduše přehlédne, že to je datum "z budoucnosti", z roku 2089. Frodo umí jednoduše manipulovat s daty, které se vrací volajícímu na základě detekce speciálního bitu v adresáři. Kdykoliv se aplikace, jako třeba virový skener nebo kontrolor integrity, pokusí zjistit velikost souboru nebo jeho obsah, dostanou se mu na základě přítomnosti značky viru podvržená data. Virus dekrementuje velikost souboru o 4096 bajtů (velikost viru), pokud je jeho datum novější nebo stejné jako 2044. Tento trik ovšem funguje pro datum před rokem 2008, protože virus přičítá k datumu 100 let a DOSové datum se počítá do roku 2107, potom přeteče a počítá se zase od začátku, což má za následek to, že Frodo začne chybovat. Je zajímavé, že virus začne ještě více chybovat po datu 2044, protože nedovede už dále nedokáže rozeznat infikované soubory od čistých (vlastně můžeme říct, že podobně jako v reálném světě, čas od času, i některý počítačový

192

Kapitola 5 – Klasifikace metod infekce paměti

virus začne stárnout, což ovšem nebyl úmysl jeho autora). V takovém případě se všechny soubory považují za infikované a jejich velikost se nesprávně redukuje o 4096 bajtů.

5.2.5.5 Stealth na úrovni clusterů a sektorů Bulharský virus Numer_of_the_Beast používá zajímavě vylepšenou techniku stealth. Virus infikuje soubory, ale změny ukrývá zavěšením se na INT 13h (disková obsluha BIOSu). Na začátek souboru se připojí použitím klasické parazitické techniky, ovšem neinfikuje takové soubory, jejichž poslední cluster nemá alespoň 512 bajtů volného místa.

Nápad je to jednoduchý a je založený na faktu, že většina DOSových disků je naformátovaná s velikostí clusteru 2048 bajtů. Jedná se tedy o minimální velikost, kterou soubor na disku zabere, i když je dlouhý třeba jenom jeden bajt, což znamená, že cluster, podobně jako sektor, obsahuje nevyužité prázdné místo.

Numer_of_the_Beast toto místo využívá k uložení přepsané části hostitele. I když virus není aktivní v paměti, velikost souborů zůstává stejná jako před infekcí, protože se velikost souboru zobrazuje podle adresářových položek.

Virus umí jednoduše podvrhnout obsah souboru v okamžiku, kdy k němu někdo přistupuje. Dělá to tak, že volajícímu předá původní obsah začátku souboru, který je uložený na konci clusteru. Virus používá mnoho triků a nedokumentovaných rozhraní, což jej činí závislým na konkrétní verzi DOSu. Viry menší jak 512 bajtů se mohou umístit do prázdného místa v sektoru, takže při jejich dezinfekci je klíčové přepsat jimi obývanou oblast jiným vzorem, třeba nulami. V opačném případě se může stát, že antivirové programy vytvoří v paměti kopii mrtvého viru (tzv. ghost positive). Jedná se o speciální případ zachycení části nebo celého kódu počítačového viru, který ale není aktivní. K tomu může dojít tehdy, když virus menší jak 512 bajtů infikuje prázdné místo v sektoru a dezinfekční program obnoví původní obsah hostitele, ale už nepřepíše kód viru. Protože BIOS čte soubory po sektorech, bude virový kód nahrán do paměti ve své neaktivní formě, což může paměťový skener chybně detekovat jako infekci Obrázek 5.3 ukazuje jak 1536 bajtový program zabírá na disku místo o velikosti 2048 bajtů (1 cluster) a jak virus "recykluje" prázdné místo v původním programu. Po infekci ukáže příkaz DIR velikost souboru 1536 bajtů, i když virus není aktivní v paměti. Virus tedy používá adresářovou techniku stealth, pro antivirové programy a kontrolory integrity dat jsou změny v souborech stále viditelné.

Počítačové viry – analýza útoku a obrana

Obrázek 5.3

193

Stealth virus na úrovni clusterů.

5.2.5.6 Stealth na úrovni hardware A konečně se dostáváme k opravdu velmi sofistikované technice, kterou je stealth na hardwarové úrovni, kterou používá ruský boot virus Strange7 napsaný v roce 1993. Strange se zavěsí na INT 0Dh, které komunikuje s IRQ 5. Na XT systémech je po završení volání INT 13h buffer vyplněný daty a hardware vygeneruje INT 0Dh. Strange se na toto přerušení zavěsí a je schopný dále odposlouchávat každou operaci čtení z disku poté, co je buffer vyplněný daty. V rutině INT 0Dh virus použije port 6 pro získání ukazatele na diskový buffer a zkontroluje, zda-li je buffer infikován. Pokud se virus v bufferu sám najde, bude buffer přepsán původním obsahem čistého sektoru a dokončí INT 0Dh. Tímto způsobem aplikace, která přistoupila k infikovanému sektoru, nebude schopna vidět nějaké změny, a to i v případě, když se pokusí volat INT 13h přímo, tedy obejitím všech možných obsluh zavěšených virem.

Na AT systémech virus nemůže použít INT 0Dh a místo toho použije INT 76h. Zavěšením se na INT 76h dovede virus monitorovat přístupy k sektorům přes porty 1F3h-1F6h. Pokud se přistoupí k sektoru kde je uložený virový kód, virus přepíše obsah portu descriptorem původního sektoru. To proto, že se INT 76h generuje před dokončením přerušení INT 13h. Bez vědomí aplikace, která přistoupila k sektoru, je přístup za běhu přesměrován na původní nezavirovaný sektor.

Obrázek 5.4 znázorňuje tři kroky, které dělají hardwarové viry k ovládnutí INT 76h.

194

Obrázek 5.4

Kapitola 5 – Klasifikace metod infekce paměti

Stealth virus na úrovni hardware.

Poznámka Trik s INT 76h nefunguje, pokud na systému běží Windows 3.0+.

5.2.6 Infekce diskové cache a systémového bufferu Velmi zajímavou strategií útoku je infekce souborů v systémovém bufferu operačního systému nebo v cache souborového systému, kterou spravuje správce cache (cache manager).

Takové viry jsou zabezpečeny jak proti monitorovacím programům sledujícím podezřelé chování (tzv. behavior blockers), tak i proti heuristické analýze. Monitorovací programy podezřelého chování se obvykle aktivují při nějaké systémové události, jako třeba otevření spustitelného souboru pro zápis a snaží se zablokovat podezřelé operace a tím zabránit virové infekci. Jsou založeny na myšlence, že viry pro svou replikaci potřebují zapisovat do souboru, takže se zdá být logické, že zablokování operací zápisu pro existující binární soubory by mohlo omezit výskyt virových infekcí.

Virus Darth_Vader byl první, který svůj kód vkládal do samotného DOSového kernelu, a to vcelku sofistikovaným způsobem – virus pro sebe nealokoval žádnou speciální paměť, protože se dovedl uložit v paměťové mezeře jádra DOSu. Potom modifikoval jádro DOSu takovým způsobem, aby získal řízení ze samotného operačního systému bez nutnosti modifikovat tabulku vektorů přerušení.

Počítačové viry – analýza útoku a obrana

195

Tímto způsobem virus dokáže monitorovat spustitelné soubory ověřováním, zdali nějaký takový soubor nebyl zařazen do systémového bufferu – virus umí modifikovat soubor uvnitř tohoto bufferu! Infekce diskové cache a systémového bufferu se obvykle implementuje dutinovou technikou, takže se virus nemusí starat o prodlužování souboru, což by mu přineslo jisté komplikace.

Tato infekční strategie byla také implementována na systémech Windows 9x rodinou virů W95/Repus, jehož autor si říká Super. Virus Repus používá zajímavý trik k tomu, aby se dostal do režimu jádra, kde je schopný volat VxD funkce pro získání obsahu cache všech souborových systémů. Jestliže virus v cache najde PE soubor, zapíše se do jeho hlavičky a označí stránku jako špinavou (dirty). Pokud je soubor kopírován z jednoho místa na druhé, virus vloží svůj kód do cachovaných bufferů, a pak vůbec nepotřebuje soubor otevírat pro zápis – stačí mu, aby jednoduše počkal do doby, než soubor sami překopírujete někam jinam. Poté virus zaútočí na tuto kopii v paměti (viz zjednodušený nákres na obrázku 5.5).

Obrázek 5.5

Virus infikující diskovou cache.

5.3 Dočasné paměťové rezidentní viry Lehce exotičtější typ počítačového viru nebývá vždy rezidentní v počítačové paměti. Namísto toho zůstává v paměti pouze krátkou chvíli nebo do doby vzniku nějaké události. K tomu může dojít po úspěšné infekci určitého množství souborů. Například bulharský virus Anthrax používá tuto techniku. Anthrax infikuje MBR a instaluje se do paměti během bootování infikovaného PC. Virus zůstává v paměti až do doby, než se mu povede infikovat jeden EXE soubor. Potom se odstraní z paměti4 a stane se infektorem přímé akce, který napadne další soubor pouze tehdy, pokud dojde ke spuštění infikovaného souboru.

Takové viry mají menší pravděpodobnost, že budou úspěšné ve svém šíření. Viry přímé akce se dají jednodušeji postřehnout, protože nápadně zvyšují aktivitu disku, zatímco permanentně rezidentní viry jsou více infekční a šíří se mnohem větší rychlosti než ty dočasně rezidentní.

Existuje nicméně pár úspěšných virů, jako třeba DOSový virus Monxla z Maďarska, který používá podobnou techniku pro infikování souborů. Monxla monitoruje přerušení INT 20h (ukončení programu a návrat do DOSu). Virus zůstává aktivní v paměti společně hostitelem a odposlouchává toto přerušení

196

Kapitola 5 – Klasifikace metod infekce paměti

a rychle infikuje všechny COM soubory v aktuálním adresáři. Tímto způsobem se virus dovede rychle šířit na nové operační systémy a zabránit postřehnutí uživatelem kvůli aktivitě disku, která je typicky během spouštění a ukončování programů zvýšená.

5.4 Swapovací viry Další exotická technika, kterou počítačové viry občas používají, spočívá v natažení malé části virového kódu do paměti, která se následně postará o zavěšení se na nějakou událost. Jakmile k této události dojde, virus nahraje segment virového kódu z disku do paměti, infikuje pomocí něj další objekty a potom se zase z paměti odstraní.

Ačkoliv se může zdát, že tato technika má značné výhody – už jenom kvůli faktu, že virus spotřebuje méně fyzické paměti a zůstává po většinu času v zakódovaném tvaru – má také své nevýhody, například zvýšený projev diskové aktivity, díky které se dá virus snadněji odhalit.

5.5 Viry v procesech (v uživatelském režimu) Na moderních operačních systémech podporujících multitasking používají viry poněkud odlišnější strategie. Virus se nemůže stát "rezidentním" v tradičním smyslu slova, ale obvykle mu stačí, když se spustí jako součást nějakého procesu.

Paměťový prostor je rozdělen na bezpečnostní okruhy asociované s režimem procesorů. Většina moderních operačních systémů, jako třeba systémy založené na Windows NT, oddělují regulérní aplikace, které běží v uživatelském režimu od těch, které běží v režimu jádra, jako je třeba samotný operační systém, ovladače a bezpečnostní datové struktury – to kvůli bezpečnosti a stabilitě systému. Z tohoto důvodu nemohou aplikace zasahovat do jádra systému, jak bylo běžné u programů pro DOS. Útočník má několik možností: 

Virus se načte s infikovaným procesem, získá řízení s použitím některé z technik uvedených v této kapitole, v samotném běžícím procesu vytvoří thread (nebo sadu threadů) běžící v uživatelském režimu a infikuje soubory za pomoci technik přímé akce.



Virus se načte před samotným hostitelským programem – nevytvoří žádné thready, ale infikuje soubory před jeho obnovením, obvykle prostřednictvím dočasného souboru na disku a jeho spuštěním společně s předáním původních parametrů příkazové řádky. Jedná se o primitivní, avšak častý způsob infekce.



Virus může také běžet jako svůj vlastní proces v uživatelském režimu.



Virus může dále použít Service Control Manager (SCM, správce řízení služeb) ke svému načtení jako obslužný proces (service process).



Viry rezidentní v procesu (per-process resident) se mohou v uživatelském režimu zavěsit na API a replikovat se při jejich volání hostitelským programem.



Virus může použít techniku vložení DLL – nejjednodušší způsob, jak to provést, je načíst DLL modifikací jednoho klíče v registru systému Windows. Jakmile se spustí hostitel, virová DLL

Počítačové viry – analýza útoku a obrana

197

knihovna se automaticky načte do hostitelského procesu. Rootkity pro uživatelský režim tuto techniku obvykle kombinují se zavěšením na API pro dosažení rezidentnosti v rámci procesu. 

Některé hybridní viry se rovněž načítají do režimu jádra, zavěsí se na události systému, ale své infekční rutiny spouští z uživatelského režimu prostřednictvím uživatelských API.

Některé tyto techniky jsou podrobněji rozebrány (společně s technikami skenování paměti) v kapitole 12, která je věnována skenování paměti a dezinfekci.

5.6 Viry v režimu jádra (Windows 9x/Me) Několik virů se na systémech Windows 9x a ME dokáže zavěsit na souborový systém pomocí VxD (specifické ovladače Windows 9x pro režim jádra) API IFSMgr_InstallFileSystemApiHook()8. Autoři virů nicméně přišli na to, že není nutné vytvářet VxD moduly, protože regulérní PE soubory na systémech Windows 9x mohou volat funkce režimu jádra s pomocí triku volání skrze bránu (tzv. mechanismus "call gate"). Virus W95/CIH je nechvalně známým představitelem viru, který využívá přístupu k portům v režimu jádra, aby poškodil hardware systému přepsáním obsahu jeho FLASH BIOSu.

5.7 Viry v režimu jádra (Windows NT/2000/XP) Infis byl prvním paměťově rezidentním parazitickým virem pro režim jádra ve formě ovladače pro prostředí Windows NT. Jedna varianta viru pracuje pouze pod Windows NT, druhá podporuje Windows 2000.

Virus zůstává v paměti jako ovladač pro režim jádra a zavěšuje se na hlavní obslužné přerušení NT systému INT 2Eh (tzv. systémové volání, syscall) takovým způsobem, že se dovede replikovat za běhu kdykoliv, když se otevře nějaký soubor. Tato metoda zavěšení na souborový systém je sice dost nestandardní a nemůže být 100% úspěšná, ale naneštěstí je pro virus zcela dostatečná.

Instalační rutina zkopíruje virus do systému a zaregistruje jej v registrech. Virus připojený na konec infikovaného souboru s celou svou PE hlavičkou, se extrahuje jako samostatný ovladač INF.SYS do adresáře %SystemRoot%\system32\drivers a nainstaluje do registrů příslušný klíč, který zajistí načtení viru do paměti při příštím startu systému: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\ inf Type = 1 Start = 2 ErrorControl = 1

Každý ovladač potřebuje mít tuto položku v registrech – z toho důvodu, aby o něm SCM věděl a načetl jej při každém startu operačního systému. A podobně – jako každý jiný driver – vyžaduje na systémech Windows NT a 2000 restart.

Jakmile virový ovladač získá řízení, alokuje paměť z nestránkované oblasti a načte tam celou svoji kopii ze souboru INF.SYS pro další použití infekční rutinou. Nakonec se virus zavěsí na INT 2Eh přepsáním tabulky descriptorů přerušení (IDT, Interrupt Deskriptor Table), viz obrázek 5.6. Protože virus běží v režimu jádra, může si v systému dovolit i ty nejodvážnější věci.

198

Kapitola 5 – Klasifikace metod infekce paměti

INT 2Eh normálně ukazuje na funkci KiSystemService(), nicméně jakmile se tam virus zavěsí, převezme řízení před samotnou funkcí KiSystemService(), která má podle tabulky systémových služeb zavolat příslušnou NTOS funkci jádra.

Win32 aplikace normálně volají API ze subsystému Win32, subsystém přeloží dokumentovaná API volání na nezdokumentovaná, které jsou exportované z NTDLL.DLL a které se nazývají jako nativní API. Tato DLL knihovna se mapuje do uživatelského režimu, ale kvůli mnoha funkcím se přepíná do režimu jádra prostřednictvím obslužného přerušení INT 2Eh s ID příslušné funkce v registru EAX (na platformě IA32). Každé otevření souboru tedy zachytí služba viru (podobně jako v případě DOSových TSR virů). Závěsná funkce viru Infis odposlouchává pouze operaci otevření souboru, pak zkontroluje jméno souboru a jeho příponu, otevře jej a pokud se jedná o PE soubor, tak jej ihned napadne.

Obrázek 5.6

Virus pro režim jádra, který pracuje na systémech Windows NT.

Jak můžete Infis odhalit na napadeném počítači? Je možné získat seznam načtených ovladačů, na druhou stranu mohou takové viry použít stealth techniky ke svému ukrytí. Ve Windows 2000/XP je seznam ovladačů umístěn v Ovládacích panelech, kde vyberete položku Nástroje pro správu. Pak vyberte položku Správa počítače a zde zvolte Správce zařízení. A nakonec v menu Zobrazit zaškrtněte volbu Zobrazit skrytá zařízení. Ovladač Inf by se pak měl objevit v seznamu, viz obrázek 5.7, který byl získán ze systému infikovaného virem Infis.

Počítačové viry – analýza útoku a obrana

Obrázek 5.7

199

Vlastnosti ovladače Inf viru Infis.

Virus Infis má mnohá omezení. Autor viru zřejmě neporozuměl některým principům Windows NT a tak Infis postrádá systémová oprávnění pro většinu přístupů k souborům, protože nevytvoří v režimu jádra infekční thread, čímž tak nepřekoná omezení uživatelského režimu, ve kterém thread běží. Výsledkem toho všeho je, že pokud program neběží v kontextu administrátora s příslušnými právy, viru se nepodaří zapsat do souboru a infekce skončí neúspěšně.

Další omezení je to, že každé ID číslo služby je vytvořeno makrem, když Microsoft kompiluje jádro, a tak se tato čísla mohou u různých verzí systému Windows lišit. Protože Infis používá pevná ID čísla, není kompatibilní se všemi verzemi Windows, ačkoliv existují spolehlivé metody, kterými lze tato ID zjistit. V budoucnu tedy můžeme očekávat, že viry si s touto překážkou poradí.

5.8 Viry vkládající se do paměti přes síť Vyspělé počítačové červy, jako třeba CodeRed nebo Slammer, vkládají svůj kód do zásobníku zranitelného procesu, který je připojen k síti. Virus se neprojevuje jako objekt uložený na disku – místo toho dokáže cestovat na nové systémy jako sada síťových paketů.

Tyto velmi důležité techniky, stejně jako další útoky na paměť ve Win32, jsou podrobně rozebrány v kapitole 12.

200

Kapitola 5 – Klasifikace metod infekce paměti

Odkazy 1. Jim Bates, "666 – The Number of The Beast", Virus Bulletin, květen 1990, str. 13-15.

2. Dr. Alan Solomon, "Mechanism of Stealth", Computer Virus and Security Conference, 1992, str.

232-238.

3. Peter Ferrie, soukromá komunikace, 2004.

4. Fridrik Skulason (se spoluautorem Dr. Vesselinem Bontchevem), "The Bulgarian Computer Viruses, The Virus Factory", Virus Bulletin, červen 1990, str. 6-9.

5. Peter Szor, "HPS", Virus Bulletin, červen 1998, str. 11-13.

6. Peter Szor, "Stealth Survival", Virus Bulletin, červenec 2002, str. 10-11.

7. Eugene Kaspersky, "Strange", http://viruslist.com/eng/viruslist.html?id=2836.

8. Paul Ducklin, "Not the Virus Writer’s Guide to Windows 95", Virus Bulletin Conference, 1996, str.

IX-XXIV.

KAPITOLA 6 Základní obranné strategie virů „Máme všechny důvody k tomu, abychom věřili, že díky tomu, že se softwarové technologie vyvíjí už přes celé jedno století, vyvstane na tomto poli spousta nových důležitých a zajímavých problémů, které budeme muset řešit."

– Dr. Steve R. White, Výzkumné centrum IBM Thomas J. Watsona

202

Kapitola 6 – Základní obranné strategie virů

Tato kapitola ilustruje nejběžnější obranné techniky, které viry používají proto, aby přežily co nejdéle – i na systémech, které jsou chráněny nějakým obecným řešením, jakým může být například antivirový monitorovací program. Vývoj obranných systémů proti počítačovým virům bez zohlednění těchto technik je jistou cestou k neúspěchu.

6.1 Tunelující viry Paměťově rezidentní viry často používají tunelovací techniky k obejití systémů sledujících podezřelé chování (tzv. behavior blockers)1. Rezidentní tunelující viry se snaží najít první článek volání přerušení, čímž obejdou všechny ostatní rezidentní aplikace. Volají tedy přerušení přímo ve vstupním bodě původní obsluhy, takže obejdou i antivirové monitorovací programy.

Nerezidentní viry rovněž používají tyto techniky k nalezení původní obsluhy a jejího přímého volání, nicméně většina tunelujících virů je paměťově rezidentní.

V následujících částech se dozvíte o některých běžných tunelovacích metodách.

6.1.1 Skenování v paměti původní obsluhy Na počítačích s DOSem je možné vyhledávat (scan) v celé fyzické paměti, což virům umožňuje hledat krátký sled instrukcí představujících začátek původní obsluhy přerušení, třeba INT 21h nebo INT 13h.

Ano – dokonce i kód BIOSu je dostupný pro čtení.

Poté, co virus získal adresu INT 21h, se může zavěsit na přerušení umístěním instrukce skoku na začátek obslužné rutiny INT 21h (tak to třeba dělá virus Frodo). Voláním původní obsluhy se virus obejde bez změny přerušení, což by mohlo být nekompatibilní s nainstalovaným softwarem. Pokud je na počítači například nainstalovaný systém pro šifrování disku, může takový virus obejít šifrovací ovladač a způsobit pád systému. Jedná se o obecný problém tunelování, ale mějte na paměti, že počítačové viry nemusejí být dokonalé (narozdíl od antivirů).

Virus Eddie (známý také jako Dark_Avenger.1800.A) byl první mezi těmi, které jsem analyzoval a které používají tuto techniku pro nalezení původního vstupního bodu obsluhy INT 13h pro řadič MFM. Autoři tunelovacích virů často používají a dokonce i vytvářejí enginy ve formě plug-inů, aby umožnili méně zkušeným autorům vytvářet nové viry tohoto druhu.

6.1.2 Trasování s pomocí ladících rozhraní Bulharský virus Yankee_Doodle byl jedním z prvních virů, kteří používali INT 1 k trasování původních obsluh přerušení jako tunelovací techniku.

Myšlenka spočívá v zavěšení se na INT 1, zapnutí příznaku trasování na procesoru a zavolání neškodného přerušení. INT 1 se pak bude volat pokaždé, kdy dojde ke spuštění instrukce a virus tak může trasovat cestu, dokud nenarazí na příslušnou obsluhu, jako třeba INT 21h. Potom si virus uloží adresu obsluhy a může jí použít, případně se na ni zavěsit, čímž tak obejde nainstalované systémy pro sledování podezřelého chování.

Počítačové viry – analýza útoku a obrana

203

Je pochopitelné, že viry se musí starat o mnoho problémů, které nastanou během trasování. Některé instrukce mohou ovlivňovat příznak trasování a zabránit tak trasování kódu. Virus tedy musí cestu vykonávání kontrolovat a předcházet takovým situacím.

6.1.3 Tunelování na bázi emulace kódu Bezpečnou alternativou k předchozí metodě je použití emulátoru kódu, který dostatečně simuluje vykonávání procesoru, takže se virus dostane k požadovanému vstupnímu bodu bez použití ladícího rozhraní. Tuto techniku jako první představil nechvalně známý australský magazín VLAD ve formě tunelovacího enginu pro obecné použití.

6.1.4 Přístup k disku přes I/O porty Běžnou technikou obrany proti kopírování je získání přímého přístupu na pevný disk a diskety tzv. "mluvením přímo se železem", a to skrze I/O porty. Nejenom to, že je to matoucí pro analýzu (vyznat se v sekvencích portů je o něco obtížnější), ale také to umožňuje přístup na disk na nižší úrovni (bez použití přerušení nebo API). Také je dovoleno zadávat příkazy, které by přerušení nebo API nepovolilo.

Nevýhody této techniky jsou zřejmé. Podobně jako ochrany proti kopírování, viry používající tyto techniky mohou být nekompatibilní napříč různými systémy a takový virus je jednoduše méně infekční než viry, které infikují z vyšších úrovní.

Tuto techniku použilo pouze několik známých virů, příkladem může být slovenský virus NoKernel.

6.1.5 Použití nedokumentovaných funkcí Jiné viry používají nedokumentované API k získání přístupu k původní obsluze. Jako už bylo zmíněno dříve, získání znalostí o nedokumentovaných rozhraních a souborových formátech patří mezi nejdůležitější výzvy, před kterými stojí seriózní antiviroví výzkumníci.

První viry od Dark Avengera používaly trik s voláním "Získej seznam seznamů" (Get List of Lists) INT 21h, což byla interní funkce DOSu2. Protože nebyla Microsoftem zdokumentována, bylo obtížné porozumět tomu, co virus dělal se strukturami. Podle všeho virus voláním této funkce získal řetěz systémových ovladačů zařízení, čímž zjistil adresu obsluhy, kterou potom mohl volat přímo a dokázal tak obejít monitorovací programy.

Velké části operačních systémů od Microsoftu nejsou zdokumentovány, včetně nativních API a důležitých částí API jádra, což činí analýzu virových kódů a jejich detekci mnohem komplikovanější.

6.2 Obrněné viry Termín obrněný virus prosadilo oddělení New Scotland Yard zabývající se počítačovou kriminalitou, aby popsalo počítačové viry, které jsou ještě obtížněji detekovatelné a analyzovatelné.

Hlavním cílem počítačového viru je rozšířit se co nejvíce – a nejlépe bez toho aniž by virus někdo postřehl. V předchozích kapitolách jste se dozvěděli o vylepšených technikách, jako třeba stealth, které dovedou virový kód ukrýt a zamezit tak jeho rychlému odhalení. Autoři obrněných virů si chtějí být jisti,

Kapitola 6 – Základní obranné strategie virů

204

že kód jejich virů bude pro skenery ještě hůře detekovatelný, a to i za použití heuristických metod, které dovedou odhalit i neznámé počítačové viry. V případě, že je virus zachycen, si autor přeje, aby analýza kódu jeho viru byla co nejsložitější, aby prodloužil dobu reakce na útok.

Následující části rozebírají tyto základní metody obrněných virů: 

Obrana proti disassemblování.



Obrana proti ladění.



Obrana proti heuristické analýze.



Obrana proti emulaci.



Obrana proti záchytným souborům.

6.2.1 Obrana proti disassemblování Počítačové viry napsané v assembleru jsou velkou výzvou pro lidi, kteří se snaží porozumět kódu, protože často používají triky, které normální programy nepoužívají nebo je používají jen velmi zřídka. Na trhu existuje několik dobrých disassemblerů, které tuto práci usnadňují. Pro analýzu virů silně doporučuji program IDA (Interactive DisAssembler) od společnosti Data Rescue, který dovede redefinovat kód a data za běhu.

Některé disassemblery dovedly v minulosti získat velký úspěch, jako třeba téměř automatizovaný disassembler Sourcer. K zamezení takové analýzy autoři virů vymysleli techniky, které tato řešení obelstí.

Největší útoky na disassemblery spočívají v technikách matení kódu, jakými je třeba kódování, polymorfismus a zejména metamorfismus. Protože je velmi důležité popsat tyto techniky podrobněji, je kapitola 7 o vylepšených technikách vývoje kódu věnována právě jim.

6.2.2 Zakódovaná data Logickým způsobem, jakým lze zabránit disassemblování, je použití zakódovaných dat v těle viru.

Všechny datové konstanty ve viru se dají zakódovat – jakmile je takový virus načtený disassemblerem, virový kód se bude odkazovat na zakódovaná data, která je potřeba nejprve dekódovat, aby bylo možné porozumět tomu, co s nimi virus dělá, čímž se analýza viru docela znepříjemní.

Například červ W95/Fix2001 zasílá ukradené přihlašovací informace útočníkovi na jeho e-mail. Autor červa si nepřál, aby se rychle přišlo na adresu, na kterou se údaje zasílají, a proto prohlédnutí červího souboru a ani otevření v disassembleru nic takového neodhalí. Ostatně – uhádli byste, co skrývá zakódovaný blok dat na obrázku 6.1?

Obrázek 6.1

Zakódovaná data červa W95/Fix2001.

Počítačové viry – analýza útoku a obrana

205

Když analyzujete červa v disassembleru pomocí nástroje IDA, naleznete decryptovací rutinu, která používá dekódování pomocí jednoduché operace XOR. Decryptovací smyčka dekóduje 87h bajtů konstantní hodnotou 19h směrem dozadu (viz obrázek 6.2).

Poznámka Instrukce "xor byte ptr encrypted[ecx],19h" může být rovněž zobrazena jako "xor byte ptr [ecx+004048DB],19".

Obrázek 6.2

Decryptor dat červa W95/Fix2001.

Abyste mohli v analýze pokračovat, potřebujete data dekódovat. Můžete třeba použít debugger, který zabere o něco času více a trochu zkomplikuje vaši analýzu. Dekódovaná data pak budou vypadat jako na obrázku 6.3.

Obrázek 6.3

Dekódovaná data z červa W95/Fix2001.

Mnohokrát už došlo k publikování nesprávných informací týmem nekompetentních virových analytiků. K tomu dochází ještě častěji, pokud je virus zakódovaný. Takové dezinformace se často dostanou do médií, čímž způsobí škody dezinformováním uživatelů o skutečném nebezpečí. Jedinou spolehlivou cestou je poctivá zevrubná analýza – cokoliv jiného je neprofesionální a mělo by být od toho upuštěno.

6.2.3 Matení kódu pro znesnadnění analýzy Jinou možností, kterou může útočník použít pro vyřazení disassembleru ze hry, je samomodifikující se kód. Takový kód se v disassembleru pak čte poměrně hůře.

Uvažme jednoduchou funkci zápisu souboru pod DOSem: MOV

CX, 100h ; tolik bajtů

Kapitola 6 – Základní obranné strategie virů

206 MOV

AH, 40h ; k zapsání

INT

21h

; použij hlavní obsluhu DOSu

Takový kód je velmi snadno čitelný, čehož si je útočník dobře vědom. Heuristické analyzátory, které používají disassemblování tyto sekvence, jej umí odhalit.

Pokud je kód zapsaný následujícím matoucím způsobem (viz výpis 6.1), je zapotřebí učinit vlastní výpočty, abychom se dozvěděli, která funkce se nakonec zavolá. Proto můžete dát přednost debuggeru, nicméně útočník může do kódu zanést i techniky zaměřené proti ladění, čímž debugger vyřadí z provozu.

Výpis 6.1 Lehce zmatený kód.

MOV

CX,003Fh

; CX=003Fh

INC

CX

; CX=CX+1 (CX=0040h)

XCHG

CH,CL

; prohoď CH a CL (CX=4000h)

XCHG

AX,CX

; prohoď AX a CX (AX=4000h)

MOV

CX,0100h

; CX=100h

INT

21h

Jakmile se vykonávání kódu dostane k INT 21h, registry už budou příslušně nastaveny. Útočník také může zanést do kódu různé instrukce skoku, což práci disassembleru stíží, zejména tehdy, pokud je několik kilobajtů kódu použito jen proto, aby kód skákal sem a tam a jenom vás popletl. Předchozí kód se dá jednoduše překonat s pomocí emulátoru kódu uvnitř skeneru. Ten ovšem může útočník opět zmást s pomocí technik obrany proti emulaci.

6.2.4 Matení kódu založené na míchání operačních kódů Vezměme v úvahu příklad uvedený na obrázku 6.4, který byl vybrán z viru W98/Yobe. Všimněte si, že instrukce CALL má offset 4013E6+1. +1 je vedlejší efekt operačního kódu B8h (MOV), který byl vložen do kódu, aby znesnadnil proces disassemblování.

Obrázek 6.4

Matení, kdy jsou ve viru W98/Yobe míchány operační kódy.

Naštěstí – moderní disassemblery, jako třeba IDA, umí rychle instrukce redefinovat jako data. Jakmile se redefinuje B8h, je tok kódu opět jasný, viz obrázek 6.5.

V praxi se dvojice instrukcí CALL/POP velmi často používá v tělech počítačových virů pro zjištění jejich přesného umístění v paměti. Instrukce CALL uloží do zásobníku offset, na kterém se nachází kód, kam se má vrátit. Ten se ihned vyzvedne zásobníku a díky těmto dvěma instrukcím virus ví, kde se právě

Počítačové viry – analýza útoku a obrana

207

nachází. Předchozí trik také může zmást heuristické skenery, které používají disassemblování, protože jednoduše minou dvojici CALL/POP.

Obrázek 6.5

Správně disassemblovaný kód redefinicí bajtu B8h jako data.

6.2.5 Používání kontrolních součtů Mnoho virů používá nějaký druh kontrolního součtu, třeba algoritmus CRC32 nebo něco jednoduššího, aby omezily výskyt čitelných řetězců ve svém těle. Kód se dá jednoduše číst, ale jeho smysl může být matoucí. V některých případech se může stát z takové metody velmi šikovné puzzle. Virus W95/Drill3, napsaný autorem Mental Driller, obsahuje podobný trik. Virus hledá jména API podle jejich kontrolních součtů, které jsou uloženy v těle viru. Když jsem virus analyzoval, nemohl jsem rozluštit některé kontrolní součty API tak, aby dávaly nějaký smysluplný řetězec. Ve skutečnosti bylo několik API použito jenom jako obrana proti emulaci, takže nebyly nezbytné pro správnou funkci virového kódu.

V mém článku o W95/Drill pro Virus Bulletin jsem nikdy přesně nevysvětlil, jakým API některé kontrolní součty odpovídají. Pár měsíců poté, když jsme konečně získali zdrojový kód viru z časopisu, jsem našel tyto řádky: ;; DWORD GetCurrentProcessID(void) dd

8D91AE5Fh, 0

Správné jméno API je ovšem GetCurrentProcessId(). Protože byl poslední znak jména API zapsaný nesprávně, přepočítaný kontrolní součet nemohl nikdy odpovídat žádnému konkrétnímu jménu API. Takže další záhada odhalena.

6.2.6 Komprimovaný matoucí kód Mnoho úspěšných počítačových červů, jako třeba W32/Blaster (ten je více zmiňován v kapitole 10), je napsáno ve vysokoúrovňových jazycích. Útočník často používá komprimaci, protože sebou nese určité výhody – například zmenšení těla viru. Také analýza takového kódu je mnohem obtížnější, protože je potřeba spustitelný kód nejprve rozpakovat. Skenery a heuristické analyzátory jsou tak vyřazeny ze hry, pokud v sobě nemají zabudovanou příslušnou podporu.

Existuje celkem 500 dobrých verzí pakovačů, které mohou útočníci použít. Naštěstí je mnoho z nich chybových a nejsou schopny běžet na všech Win32 platformách. Existuje několik takových řešení, jako třeba ASPack a ASProtect, které podporují polymorfismus pro příslušné komprese, stejně jako formy obrany proti ladění. Ostatně je známo, že ASPack používá polymorfní engine z viru W95/Marburg4.

208

Kapitola 6 – Základní obranné strategie virů

Podívejte se na obrázek 6.6, kde je ukázaný příklad z viru W32/Blaster. Hlavička souboru červa sice neobsahuje obvyklá jména sekcí, nicméně vám prozradí jméno pakovače, kterým je UPX.

Obrázek 6.6

PE hlavička červa W32/Blaster.

V těle červa je dále možné najít části řetězců, jak je vidět na obrázku 6.7.

Obrázek 6.7

Části řetězců v pakovaném červovi W32/Blaster.

Aby se dal kód dobře analyzovat v disassembleru, musí se nejprve rozpakovat. Můžete se o to pokusit prostřednictvím nějakého Win32 debuggeru, jako třeba Turbo Debugger, OllyDBG nebo SoftICE, ale možná budete muset čelit některým trikům na obranu před laděním. Ty jsou popsány v následující části.

6.2.7 Obrana proti ladění Útočníci mohou použít mnoho triků, které pořádně dovedou znesnadnit proces ladění. Protože je ladění podporováno hardwarem, mohou být tyto techniky závislé na platformě. V této části se dozvíte o několika takových technikách.

Některé z těchto metod jsou nekompatibilní s jistými systémy. Například DESQView/DOS byl multitaskingový operační systém na bázi DOSu, které takové triky neměl rád. Byl jsem z toho poněkud zklamaný, protože jsem pomocí těchto technik nemohl v tomto prostředí ochránit svůj antivirus Pasteur.

Tyto techniky jsou totiž užitečné k ochraně kódu antiviru a DRM (Digital Rights Management, správa digitálních zpráv) software před útočníky-začátečníky.

6.2.7.1 Zavěšení INT 1 a INT 3 na x86 Častou technikou bývá zavěšení na přerušení INT 1 a INT 3. To je neškodné v případě normálního běhu virového kódu, ale při procesu ladění debuggery ztratí svůj kontext. Závěsnou rutinou je obvykle pouhá instrukce IRET (pokud není nainstalovaný žádný debugger). Některé viry, jako třeba V2Px používají zavěšování INT 1 a INT 3 k decryptování svého těla.

Počítačové viry – analýza útoku a obrana

209

6.2.7.2 Počítání ve vektorech přerušení INT 1 a INT 3 Namísto blokování INT 1 a INT 3 může obrněný kód jednoduchým způsobem vykonávat nezbytné výpočty v tabulce přerušovacích vektorů (IVT). Útočníci mají tento trik naučený z běžných ochran proti kopírování5 a z programu EltGuard.

Myšlenka spočívá v pravidelném používání vektorů přerušení INT 1 a INT 3 během spouštění kódu, jako třeba počítání decryptovacího klíče k dekódování další zakódované vrstvy v kódu. Sám o sobě se dá tento druh kódu snadno obejít lepším debuggerem, jakým je třeba Turbo Debugger pro virtuální 86 režim. Debuggery v tomto režimu používají virtuální stroj, takže se vektory INT 1 a INT 3 mohou měnit bez poškození vykonávání kódu.

6.2.7.3 Přepočítávání kontrolního součtu kódu pro detekci breakpointů Protože debuggery používají operační kód 0xCC (INT 3) vložený do kódu pro breakpointy, kód se změní vždy, když je umístěn nový breakpoint. Pokud běžící kód toto místo zkontroluje, debugger neposkytne původní kód a tak se dají jednoduše zjistit změny. Některé viry vytvářejí kontrolní součet svého kódu a přeruší svoje vykonávání, pokud tímto způsobem detekují přítomnost debuggeru.

Analýza založená na emulaci nijak nemění kód kvůli breakpointům, takže můžete tento trik porazit prostým použitím analyzátoru s emulací kódu.

6.2.7.4 Kontrolování stavu zásobníku během spouštění kódu Velmi jednoduchým způsobem, jakým lze detekovat debugger, je kontrolovat stav zásobníku během spouštění kódu. Debugger během krokování ukládá trasovací záznamy na zásobník, včetně CS:IP a příznaků procesoru. Jednoduchým porovnáním stavu zásobníku na danou hodnotu se dá krokování rychle detekovat, jak je vidět ve výpisu 6.2.

Výpis 6.2 Detekce krokování s použitím stavu zásobníku.

MOV

BP,SP

; Vezmeme ukazatel na zásobník

PUSH

AX

; Uložíme AX na zásobník

POP

AX

; Vyjmeme hodnotu ze zásobníku

CMP

WORD PTR [BP-2], AX

; Porovnáme se zásobníkem

JNE

DEBUG

; Debugger byl nalezen!

Části paměťově rezidentního monitoru některých antivirových produktů obsahují podobné rutiny jako ochranu před tunelovacími technikami, které používají trasování. Tunelování založené na emulaci kódu nicméně touto metodou detekovatelné nebude.

6.2.7.5 Použití INT 1 nebo INT 3 ke spuštění jiného přerušení Jedná se o metodu podobnou té přecházející, která je založená na zavěšování, ovšem místo zavěšení se na INT 1 a INT 3 s využitím nic nedělajících rutin útočník volá jiné přerušení, jako třeba původní obsluhu INT 21h. Když virus používá INT 21h, může jej používat jako náhradu INT 1.

Kapitola 6 – Základní obranné strategie virů

210

Podívejte se na následující příklad: MOV AH, 40

; zapisovací funkce

INT 3

; zavolej původní obsluhu INT 21h skrz předchozí zavěšení

Na vektoru INT 3 bude zavěšena obsluha INT 21h a předchozí funkce vykoná zápis do souboru, kterou nebude možné krokovat debuggerem.

6.2.7.6 Použití INT 3 ke vstupu do režimu jádra na Windows 9x Některé počítačové viry používají k přechodu z uživatelského režimu do režimu jádra na systémech Windows 9x trik s manipulací s příslušnou položkou v IDT. Toho se dá bohužel dosáhnout velmi jednoduše, protože na těchto systémech je tabulka IDT dostupná pro zápis. Jedná se o závažný problém – jakékoliv přerušení je asociováno s přístupem na úrovni jádra, takže v momentě, kdy virus aktivuje takovou závěsnou funkci, přepne se do "nejmocnějšího" režimu.

Na procesorech Intel 386 a vyšších IDT tabulka obsahuje offsety a selektory pro každé přerušení se speciálními příznaky. Trik spočívá v tom, že offset obsluhy je uložen ve dvou slovech, které jsou rozděleny "po stranách" položky QWORD (8 bajtů) v IDT. Existuje celkem 256 přerušení, prvních 32 položek je rezervováno pro výjimky procesoru, zbytek jsou softwarová přerušení. Adresa IDT je přístupná přes instrukci SIDT, která přečte obsah registru IDTR procesoru, který obsahuje ukazatel na IDT. Jako obrana proti ladění může sloužit zavěšení na INT 3 v IDT a spuštění kódu přes tuto obsluhu. Tato technika poplete debuggery jako je třeba SoftICE, zejména v případě, že se v nich pro trasování a analýzu virového kódu používají breakpointy.

Toto je přesně ten způsob, jakým virus W95/CIH skáče do režimu jádra, přičemž se současně jedná o techniku obrany proti ladění. Podívejte se na výpis 6.3.

Výpis 6.3 "Ó můj drahý!" – Ring 0.

PUSH

EAX

SIDT

FWORD PTR [ESP-2]

POP

EBX

; a přesun ji do EBX

ADD

EBX, 1CH

; ukazuje do místa položky INT 3

MOV

EBP, [EBX]

; Získej horní polovinu

MOV

BP, [EBX-4]

; A zbytek obsluhy INT 3

LEA

ESI, NEW_HANDLER

; Offset nové obsluhy v ESI

MOV

[EBX-4], SI

; Nastav spodní polovinu v IDT

SHR

ESI, 10H

MOV

[EBX+2], SI

; Nastav horní polovinu v IDT

INT

3

; Spusť novou obsluhu v okruhu 0

CLI

; Získej adresu IDT

; (3*8+4 = 1Ch)

Počítačové viry – analýza útoku a obrana

211

Virus CIH se v SoftICE trasovat nedá, nicméně by se daly použít ladící registry pro krokování do kódu viru bez použití INT 3. Předcházející kód na systémech Windows NT/2000/XP/2003 porušuje bezpečnostní a obecné ochrany a vede k vyvolání výjimky, kterou CIH dovede zachytit svojí obsluhou výjimek.

Virus dokáže tento trik použít, pokud má udělena příslušná práva.

6.2.7.7 Použití INT 0 pro generování výjimky dělení nulou Už jsem zmínil dříve, že virtuální 86 režim Turbo Debuggeru je výborným řešením, který si poradí s obrněným kódem, nicméně i proti němu existuje několik možných útoků. Útočník se například může zavěsit na INT 0 kvůli generování výjimky dělení nulou a spustit následující instrukci jako "obsluhu", což Turbo Debugger nezvládne. Příkladem virů, které používají tuto techniku, jsou například viry Velvet a W95/SST.951.

6.2.7.8 Použití INT 3 pro generování výjimky Variantou předešlé metody je generování výjimky na 32bitových systémech Windows s obsluhou, která jí zachytí. Tímto způsobem se dokáže virový kód jednoduše zotavit, ale debugger na aplikační úrovni, jako je třeba Turbo Debugger, ztratí kontext, protože obsluha výjimek se odehrává v režimu jádra.

Některé viry na Win32 systémech používají ke generování výjimek INT 3. V takových případech funguje obsluha výjimek jako obecná rutina volající API s ID funkce a parametry předanými na zásobníku.

Tuto metodu používá W32/Infynca.

6.2.7.9 Používání API funkce IsDebuggerPresent() Pro útočníka je pravděpodobně nejjednodušší metodou volání API funkce IsDebuggerPresent(), která vrátí TRUE v případě, že na systému běží debugger na aplikační úrovni.

6.2.7.10 Hledání v klíčích registru pro detekci debuggeru Existuje mnoho způsobů, pomocí kterých lze detekovat moderní debuggery, jakým je třeba SoftICE. Je totiž velmi jednoduché vyhledat jejich záznamy v registrech systému Windows.

6.2.7.11 Detekce debuggeru přes seznam ovladačů nebo prohledáním paměti Existují i další způsoby, pomocí kterých lze zjistit přítomnost debuggeru. Je možné si například vyžádat seznam ovladačů a zkontrolovat, zda-li obsahuje jméno ovladače debuggeru. Ještě jednodušší metodou je vyhledání kódu debuggeru v paměti.

6.2.7.12 Dekódování s použitím SP, ESP (Stack Pointer) Virus Cascade byl prvním známým virem, který ve svém decryptoru používal registr SP (Stack Pointer, ukazatel na zásobník). Protože se zásobník používá během krokování přes INT 1, dekódování skončí neúspěchem. Jiné viry jednoduše dekódují nebo vybudují (build) své virové tělo na zásobníku, jako třeba virus W95/SK. Není tedy žádným překvapením, že takové viry je obtížné debuggerem odladit.

Kapitola 6 – Základní obranné strategie virů

212

6.2.7.13 Dekódování virového těla pozpátku Virus může použít standardní decryptovací rutinu a otočit směr decryptovací smyčky. Obvykle můžete virus trasovat, jakmile se první bajt zakódovaného těla viru dekóduje a na toto místo je vložen breakpoint. To ovšem nebude fungovat v tomto případě, protože operační kód breakpointu (0xCC – INT 3) přepíše decryptovací smyčka. Existuje několik virů, které dekódují svoje tělo pozpátku. Příkladem může být virus W95/Marburg, který generuje decryptovací smyčky, které umí dekódovat v obou směrech.

6.2.7.14 Útoky zaměřené na frontu instrukcí Whale byl pasován na "matku všech virů". Používal tolik obranných technik, že se kvůli své velké složitosti nedovedl ani pořádně replikovat. Původní varianta viru Whale se dokázala šířit pouze na systémech XT (8088) – kvůli jeho samomodifikující rutině. Jedná se o zajímavou hardwarovou závislost viru, která byla vyřešena v pozdějších variantách viru. Mnoha výzkumníkům se nepovedlo virus namnožit, protože nebyl kompatibilní se systémy 8086, AT, 386 a 486 – domnívali se tak, že virus po nějaké chvíli sám vyhyne. To se ovšem nestalo, Whale se "reinkarnoval" na řadě Pentií, alespoň tedy teoreticky, protože tyto procesory vyprazdňují svou frontu instrukcí (tzv. prefetch queue). Podíváme se nyní blíže jeho kód, abyste jej lépe pochopili.

Whale se zavěsí na INT 3 a vyvolá spuštění své obsluhy. Ta podle všeho spustí nějaké smetí, pravděpodobně kvůli chybě v počítání adresy obsluhy blízko instrukce RET. Kód je tedy úmyslně matoucí, jak můžete vidět ve výpisu 6.4.

Výpis 6.4 Matoucí trik viru Whale. pop

ax

; Vyzvedni 0xE9CF ze zásobníku do registru AX

xor

ax,020C

; dekóduj 0xEBC3 v AX (0xc3 – RET)

mov

[trap],al

; přepiš INT 3 instrukcí RET

add

ax,020C

; vyplň frontu instrukcí

cs:

trap: INT

3

; Vykoná RET ; ovšem pouze tehdy, pokud je už fronta instrukcí ; plná (pouze na 8088) nebo ; vyprázdněná (Pentium+)

INT3:

; Ukazuje na smetí Invd

; Náhodné smetí (2 bajtů)

ret

Autor viru očekával, že se INT 3 nahradí instrukcí RET a převezme kontrolu na správném místě. Jeho počítač byl pravděpodobně typu XT (8088), který má čtyřbajtovou frontu instrukcí procesoru (na 8086 nahrazená šestibajtovou), a z toho důvodu kód na jeho počítači fungoval.

Počítačové viry – analýza útoku a obrana

213

Jiné viry používají útoky na frontu instrukcí, aby zmátly debuggery a emulátory. V režimu krokování (nebo emulace kódu bez podpory fronty instrukcí) se takové změny odehrávají automaticky, a tak útočník může jednoduše detekovat pokusy o trasování ověřováním, zdali jeho modifikovaný kód běží.

6.2.7.15 Vypínání klávesnice Když trasujete kód, používáte klávesnici. Útočník to samozřejmě ví a dovede klávesnici zablokovat, aby vám v trasování zabránil, a to přednastavením obsahu I/O portu 21h nebo 61h. Porty se mohou různit podle toho, na jaké adresy je operační systém mapuje.

Například DOSový virus Whale používá k vypnutí klávesnice tyto sekvence: IN

AL,21

OR

AL,02

OUT

21,AL

Další metoda spočívá v zavěšení se na přerušení INT 9 (obsluha klávesnice). To zabrání aktivaci některých debuggerů poté, co se kód spustí. Běžnou technikou k prolomení se do obrněného kódu je spuštění viru a jeho zastavení uprostřed vykonávání pomocí klávesové zkratky debuggeru. Pokud je tato klávesová zkratka vypnutá, debugger nemá šanci se dostat do kódu.

Další zajímavý útok, který používá virus Cryptor, spočívá v uložení šifrovacích klíčů v bufferu klávesnice, který je následně přepsán debuggerem6.

6.2.7.16 Použití obsluhy výjimek Mnoho Win32 virů používá obsluhy výjimek, aby ztížily proces ladění. Virus W32/Cabanas7 byl prvním, který tento trik použil. Dávejte si v kódu pozor na přístup k FS:[0], který se používá k získání a nastavení záznamu obsluhy výjimek. Také si dávejte pozor na čtení z FS:[18], protože se používá k přístupu k datům na FS: bez použití FS:. Obojí je uloženo v TIB (Thread Information Block, blok informací threadu).

6.2.7.17 Výmaz ladících (DRn) registrů Některé viry, jako třeba CIH, používají ladící registry pro účely volání "Jsi tam?". Běžící SoftICE na takto infikovaném systému dokáže zmást virus natolik, že se do paměti nainstaluje i podruhé. Přepisem ladících registrů ale může dojít k problémům při používání pokročilejších ladídích triků, jako jsou třeba ty, co používají paměťové breakpointy.

6.2.7.18 Kontrola obsahu video paměti Ačkoliv se tento nebezpečný trik ve virech příliš často nevidí, několik z nich jej používá. Myšlenka spočívá v zavěšení se na přerušení časovače (INT 8 nebo INT 1Ch), přičemž rutina nepřetržitě kontroluje obsah video paměti a vyhledává v ní svůj řetězec. Pokud virus běží a snažíte se jej najít vypsáním paměti v debuggeru, virus ve video paměti nalezne svůj vyhledávací řetězec a pak zaútočí na systém – třeba přepisem obsahu disku.

214

Kapitola 6 – Základní obranné strategie virů

6.2.7.19 Kontrola obsahu TIB (Thread Information Block) Některé viry pro Windows kontrolují, zda-li má položka v TIB na adrese FS:[20h] nenulovou hodnotu.

Tímto způsobem se dají detekovat debuggery na aplikační úrovni, ovšem během analýzy to můžete ignorovat (stačí vědět, k čemu tento trik slouží).

6.2.7.20 Použití API CreateFile() (metoda "Billyho Belcebu") Ovladače režimu jádra obvykle komunikují s komponentami Win32 v uživatelském režimu. K získání handlu ovladače může Win32 aplikace použít API CreateFile() se jménem zařízení. Například jméno SoftICE je na systému Windows 9x \\.\SICE a na Windows NT \\.\NTICE. Tato technika se jednoduše postřehne během analýzy, avšak mnoho škodlivých programů jednoduše odmítne pokračovat v případě, že detekují aktivní SoftICE. Takže, pokud je na infikovaném počítači určeném pro analýzu načtený debugger, může to ztížit úmyslnou replikaci viru, která je potřebná pro následnou analýzu viru.

Tuto techniku jako první představil autor virů, který si říkal Billy Belcebu.

6.2.7.21 Používání samo-opravného kódu k vyřazení breakpointů Některé viry, jako třeba varianty rodiny Yankee_Doodle (napsány bulharským autorem "T.P.") používaly korekci chyb s Hammingovým kódem, aby dokázaly opravit svůj poškozený kód. Hammingův kód je pojmenován po Richardu Hammingovi, který jej vymyslel ve čtyřicátých letech 20. století, aby umožnil programům nejenom detekovat chyby, které nastaly během přenosu dat, ale také některé chyby opravit (s určitými omezeními).

Virus Yankee_Doodle měl ovšem několik chyb a mohl se opravdu poškodit v případě infekce EXE souborů, jejichž ES:SP (programový zásobník) uložený v EXE hlavičce ukazoval do těla viru. Pokud se takový, nekorektně infikovaný, soubor spustí, prvotní instrukce PUSH ve virovém kódu jednoduše poškodí hlavní část těla viru, protože zásobník programu (ES:SP) omylem ukazuje přímo na virus. Virový kód na kontrolu chyb by teoreticky mohl toto poškození najít a opravit – nebo alespoň pozastavit vykonávání viru. Autor nicméně s použitím této techniky hlavně zamýšlel vyřadit breakpointy umístěné nějakými debuggery8. Pokud debugger vložil do virového kódu bajt 0xCC udávající breakpoint (INT 3), virus to rozpoznal a bajt opravil na původní, čímž nastavený breakpoint zrušil. Virový kód umí – s pomocí svých opravných záznamů – opravit až 16 breakpointů nebo jinak porušených bajtů.

6.2.7.22 Matoucí souborové formáty a vstupní body Mnoho debuggerů zhavaruje, pokud je souborový formát obsahující virus nějak speciálně zkonstruován nebo poupraven. Například je možné překrýt některé části PE souboru manipulací s jeho interní strukturou. Takové změny můžou debugger snadno zmást, protože je stavěn na "standardní" strukturu souboru. Není tedy překvapením, že občas nějaký debugger zhavaruje, když se pokusí načíst obskurní vstupní bod aplikace, který byl upraven virem. Například, jak už bylo zmíněno v kapitole 3, lokální úložiště toku (Thread Local Storage, TLS) PE souboru může sloužit jako alternativní vstupní bod na systémech na bázi NT, který se aktivuje před samotným hlavním vstupním bodem. Některé debuggery, jako třeba SoftICE, se zastaví pouze na tom hlavním, a virus je tak už aktivován přes TLS v době výzvy

Počítačové viry – analýza útoku a obrana

215

debuggeru k analýze. Obdobné problémy rovněž činí debuggerům run-time pakovače, protože v mnoha případech mění strukturu souboru.

6.2.8 Obrana proti heuristické analýze V roce 1998 byl vývoj 32bitových virů pro Windows v relativně raném stádiu9. Proto bylo vymyšleno mnoho rozličných technik infekce, které daly impuls ke vzniku heuristické analýzy zaměřené proti nim.

Heuristická analýza umožňuje detekci neznámých virů a variant již existujících virů za pomoci statických a dynamických metod. Statická heuristika spočívá v analýze souborového formátu a běžných fragmentů kódu. Dynamická heuristika používá emulaci kódu k simulování procesoru a prostředí operačního systému a k detekci podezřelých operací, ke kterým dojde "za běhu" virtuálního stroje heuristického skeneru. Autoři virů pochopitelně postupem času vyvinuli různé techniky obrany proti heuristice a emulaci.

Pečlivá analýza různých typů infekce vedla k vývoji první generace heuristických detektorů pro Win32, které používaly statickou heuristiku. Ta dovedla rozeznat podezřelé struktury uvnitř PE souborů a v případě první generace 32bitových virů pro Windows měla velmi dobrou úspěšnost detekce. Myšlenka statické heuristiky byla založena na podobných detekčních technikách, kterými se detekovaly viry pro DOS. Koncem roku 1999 už bylo vytvořeno mnoho technik replikace a co víc, většina virů pro 32bitová Windows používala nějaký typ kódovacích, polymorfních nebo rovnou metamorfních technik. Zakódované viry se obtížněji detekují – a jsou nebezpečné, když se podíváme vpřed do budoucnosti skenerů. To proto, že skenery začaly být velmi pomalé, když se pokoušely testovat větší množství čistých souborů.

Heuristické metody první generace byly extrémně úspěšné proti virům napadající PE soubory. I autoři virů tím byli překvapeni, ale jak už to bývá, netrvalo dlouho, a vždy vymysleli nějakým typ útoku proti heuristické analýze. Některé typy obrany byly dokonce vyvinuty během několika posledních let.

Někteří autoři virů dokázali vyvinout pokročilé i techniky proti nejsilnější části mnoha antivirových programů – emulátoru kódu.

6.2.8.1 Útoky proti první generaci heuristické analýzy pro Win32 Tato část popisuje útoky proti první generaci heuristické analýzy pro Win32, které představili autoři virů brzy po jejím vzniku. Následné zkoumání těchto nových metod umožnilo vylepšení heuristických skenerů, které si pak dovedly s těmito novými triky poradit. Techniky heuristické detekce jsou více rozebrány v kapitole 11.

6.2.8.1.1 Nové techniky infekce PE souborů Mnoho virů přidávalo do PE souborů novou sekci nebo se připojovalo na konec té poslední. I dnes se dá mnoho virů detekovat s použitím těch nejjednodušších možných heuristických metod. Heuristika má takovou výhodu, že ji mohou provádět i koncoví uživatelé – stačí se podívat na vstupní bod PE souboru, jestli náhodou nesměřuje do poslední sekce programu.

216

Kapitola 6 – Základní obranné strategie virů

Tato heuristika sice může produkovat falešné poplachy, ale dá se provést více testů ke zjištění, zda-li daný soubor není spíše zkomprimovaný. Komprimované PE soubory totiž nejčastěji způsobují falešné poplachy – to proto, že jejich dekomprimační kód se velmi často vkládá do poslední sekce aplikace.

Na platformě Win32 se záhy objevil velký počet komerčních run-time pakovačů PE souborů, jako třeba UPX, Neolite, Petite, Shrink32, ASPack atd. Tyto pakovače používají autoři virů a trojských koní z toho důvodu, aby ukryli obsah svých "produktů". Mnoho lidí dovede provést heuristický průzkum a mohou považovat soubor za podezřelý v případě, že obsahuje určitá slova nebo fráze. Proto autoři virů používají pakovače – aby utajili cokoliv zřejmého na pohled člověka nebo skeneru. Bohužel – červi nebo trojské koně mohou takto měnit svoji podobu. W32/ExploreZip byl první červ, který byl zapakován. Červ měl pak několik variant, které byly vytvořeny různými 32bitovými PE pakovači, jako třeba UPX. Moderní antivirový software musí umět pracovat s těmito pakovači. Skeneru by mělo být jedno, zda-li je v ZIP archivu schovaný dokument Wordu, který navíc obsahuje vložený spustitelný objekt zapakovaný jiným 32bitovým pakovačem. Skener se prostě musí dostat až k poslednímu možnému objektu a provést sken na dekomprimovaném obsahu.

Skener tedy potřebuje modul, který dovede rychle rozpoznat a prolézt zapakovaný objekt. Díky tomu pak poměr falešných poplachů výrazně poklesne. Autoři virů pak přišli na to, že je velmi podezřelé připojovat viry na konec poslední sekce a přišli s novými technikami infekce, aby vyřadili heuristickou detekci z provozu.

6.2.8.1.2 Více než jedna virová sekce Některé viry pro Win32 se připojují na konec více sekcí. Například virus W32/Resure se připojuje celkem do čtyř sekcí (.text, .rdata, .data a .reloc) v každém PE hostiteli. Protože se vstupní bod aplikace změní tak, aby ukazoval na novou sekci .text viru, heuristická analýza selže – to proto, že se řízení nesměruje do poslední sekce.

Tento virus je dále velmi kompatibilní s většinou Win32 systémů, protože je napsaný v jazyce C místo klasického assembleru. Soubor můžeme heuristicky prozkoumat sami – člověk dokáže v některých PE souborech rozpoznat 4 přidané sekce v tabulce sekcí, ale heuristický skener to má o něco těžší. To proto, že některé linkery občas vytvářejí v PE souborech podezřelé struktury, takže detekce založená na pouhém ověřování jmen sekcí není tím nejlepším nápadem.

6.2.8.1.3 Viry, které se připojují na začátek hostitele a kódují jeho hlavičku Jiný jednoduchý antiheuristický trik používají viry naprogramované ve vyšších programovacích jazycích, které se připojují na začátek hostitele. Tyto viry se nepotřebují starat o souborové formáty.

Heuristika první generace dovede zkontrolovat hlavičku PE souboru na jeho očekávaném konci. Tuto analýzu může opět provést člověk, a to i v případě, když je na konci souboru něco zakódovaného (jako je tomu v případě viru W32/HLLP.Cramb).

Je nicméně obtížnější vytvořit program, který by činil totéž, protože virus může na svém hostiteli použít nějaké kódování a heuristický program na takovém souboru s největší pravděpodobností selže.

Počítačové viry – analýza útoku a obrana

217

6.2.8.1.4 Infekce volné oblasti v první sekci Některé viry, jako třeba W95/Invir10, nemodifikují vstupní bod aplikace tak, aby ukazoval do poslední sekce. Namísto toho přepíší prázdnou oblast první sekce skokem na začátek virového těla, který je umístěn úplně někde jinde – třeba v poslední sekci.

Jak uvidíte později, tato technika se často kombinuje s triky na obranu proti emulaci. To proto, že dynamická heuristika druhé generace používá emulátor kódu proto, aby poznala, zda-li aplikace skáče z jedné sekce do druhé.

6.2.8.1.5 Infekce první sekce posunutím zbylých sekcí První známý virus, který používal tuto techniku, byl virus W32/IKX napsaný autorem, jenž si říká Murkry. Tento virus je také známý pod jménem "Mole" (krtek), které napovídá, že používá speciální dutinovou techniku infekce. Tělo viru IKX je totiž větší, takže se nevejde do jediné prázdné oblasti v sekci a tak virus musí pro sebe vytvořit "díru" technikou, kdy posune každou sekce PE hostitele. Virus se pak připojí na konec kódové sekce a následně změní offset dat každé následující sekce v souboru o 512 bajtů.

Dynamická heuristická analýza je v tomto případě nezbytná – heuristika se totiž musí provést na kódu a nikoliv na struktuře aplikace.

6.2.8.1.6 Infekce první sekce pakováním Jedním z nejzajímavějších antiheuristických virů byl W95/Aldabera, který infikuje poslední sekci PE souborů. Virus nedovede infikovat malé soubory a raději dává přednost těm větším. Pak se pokusí zkomprimovat jejich kódovou sekci.

Pokud se dá kódová sekce aplikace zkomprimovat tak, že se zkomprimovaný kód a kód viru vleze na stejné místo, virus sekci zmenší a umístí svoje tělo na její konec. Po své aktivaci virus rozpakuje kódovou sekci (podobně jako to dělá nějaký run-time pakovač).

W95/Aldabera způsobil jak obyčejným, tak i heuristickým skenerům mnohé problémy, protože virus je docela velký, dekóduje a dekomprimuje se dlouho, kódová sekce se emuluje dost pomalu a vyžaduje mnoho iterací. Virus také používá RDA (Random Decryption Algorithm, náhodný dekódovací algoritmus)11. RDA viry v sobě nenesou dekódovací klíč pro dekódování svého těla. Místo toho decryptor viru náhodným způsobem generuje klíče a dekódovací metody a zkouší se dekódovat hrubou výpočetní silou (brute-force). Tato technika je dále popsána v kapitole 7.

Virus navíc přistupuje a modifikuje velkou oblast virtuální paměti a tak emulátor musí udržovat více než 64 kB "špinavých" stránek, aby správně dekódoval kód viru, čímž se snadno překročí maximální limit některých prvních 32bitových emulátorů kódu, které se stále snažily podporovat platformu XT.

6.2.8.1.7 Techniky zatajení vstupního bodu (EPO) Různé 32bitové viry pro Windows používají velmi efektivní obranu proti heuristické analýze, které se říká technika zatajení vstupního bodu (EntryPoint Obscuring, EPO), nebo také technika vkládání.

Mnoho starších virů pro DOS tuto techniku používalo, některé z nich už byly popsány v kapitole 4 popisující klasifikace metod infekce.

218

Kapitola 6 – Základní obranné strategie virů

Jak se dalo očekávat, autoři virů nakonec vymysleli vkládací polymorfní viry, aby vyřadili heuristické skenery z provozu. Dnes toho patří mezi nejvyspělejší techniku, kterou vymysleli autoři virů.

Očekávám, že budoucí polymorfní viry s EPO budou používat schopnosti masového rozesílání. Znamením tohoto trendu je rodina virů W32/Perenast, která se rychle rozšiřuje v síťovém prostředí. W32/Perenast je výrazně matoucí virus, kterého je velmi těžké detekovat.

Je zřejmé, že antivirový software tuto dekádu nepřežije, pokud nedojde k výraznému vylepšení skenovacích enginů takovým způsobem, aby byly schopny detekovat i takto složité viry.

6.2.8.1.8 Náhodný výběr vstupního bodu v kódové sekci W95/Padania byl jedním z prvních 32bitových virů pro Windows, který příležitostně nemodifikoval vstupní bod aplikace v PE hlavičce, aby ukazoval na tělo viru. Virus občas vyhledal v relokační sekci aplikace bezpečné místo k provedení náhrady kódu v kódové sekci PE souborů a změnil určité instrukce CALL nebo PUSH na instrukci skoku JMP, která směřovala na začátek jeho těla. Virus si místo vybral blízko původního vstupního bodu aplikace – je tedy pravděpodobné, že virus získá řízení v okamžiku, kdy se spustí původní aplikace – ovšem bez jakékoliv záruky.

Jakmile virus není zakódován, detekuje se relativně jednoduše, a to těmi skenery, které se nespoléhají pouze na kontrolu vstupního bodu, ale které rovněž dovedou skenovat začátek a konec každého PE souboru na virové řetězce. Skenery, které nepodporují tento typ skenování nebo nějaký typ algoritmické detekce (ta je popsána v kapitole 11), je ovšem obtížné upravit tak, aby takové viry detekovaly.

A navíc – heuristické skenování vyžaduje schopnost pracovat s problémy, které mohou během emulace PE souborů nastat. Emulátory se obvykle zastaví, jakmile narazí na "neznámé" volání API. To znamená, že nemusí být dosaženo místa, kam virus zapsal svůj skok (JMP) směřující na jeho vlastní vstupní bod.

Problém je v tom, že různé API mají proměnný počet parametrů a právě API jsou zodpovědné za čištění zásobníku. Je jednoduše nemožné znát počet vstupních parametrů všech API, což je pouhé minimum k tomu, aby se dal sledovat další tok kódu. Někdo sice může implementovat standardní API volání, ale co se zbylými tisíci dalších DLL knihoven?

I skenování pomocí dynamické heuristiky není příliš efektivní pro detekci takových virů. Některé soubory se dají heuristicky detekovat, ovšem hlavně tehdy, pokud je skok na začátek viru umístěn někde poblíž vstupního bodu PE aplikace.

6.2.8.1.9 Využití oblastí zarovnání kompilátoru Některé viry, jako třeba W95/SK a W95/Orez využívají oblasti zarovnání kompilátoru (compiler alignment areas), které jsou v mnoha případech vyplněny nulami nebo bajty 0xCC. W95/Orez rozdělí svůj decryptor v PE souborech na malé "ostrůvky" a používá relativně krátký, avšak efektivní, permutovaný decryptor, který nahradí takové oblasti v PE souborech. Řízení je pak předáno z náhodně zvoleného místa pomocí instrukce CALL.

Počítačové viry – analýza útoku a obrana

219

6.2.8.1.10 Viry, které neoznačují žádnou sekci jako zapisovatelnou Velmi užitečnou heuristickou technikou je kontrola, jestli je kódová sekce označena jako zapisovatelná – každá taková sekce, kam směřuje vstupní bod programu, je podezřelá. Některé viry ovšem sekce nepotřebují nijak označovat nebo je označovat jako zapisovatelné, například virus W95/SK sebe dekóduje na zásobník a nikoliv na místo uložení těla viru v poslední sekci. Tento virus tedy nepotřebuje nastavovat žádné bity, stejně jako většina virů, které se dekódují na zásobníku. Heuristický skener pak má menší šanci takové viry detekovat.

6.2.8.1.11 Správná infekce souboru První generace heuristických skenerů kontrolovala strukturu souborů na přesnost. Některé viry první generace totiž modifikují strukturu souboru tak, že jej poškodí. Jakmile se někdo pokusí spustit na systémech Windows NT/2000 takto nekorektně infikovaný soubor, systémový zavaděč odmítne spustit takovou aplikaci.

Bohužel – většina 32bitových virů pro Windows je už klasifikována jako Win32, což znamená, že jejich infekční strategie funguje správně na více než jednom Win32 systému, což má za důsledek, že heuristická detekce, která je založena na tomto principu, v případě takových virů selže.

6.2.8.1.12 Přepočítání kontrolního součtu Další možnou heuristickou technikou je přepočítání kontrolního součtu systémových DLL knihoven, jako třeba KERNEL32.DLL. Pokud kontrolní součet neodpovídá, Windows 95 se nezdráhá načíst i takové soubory (pokud pochopitelně nedošlo k výraznějšímu poškození). Win32 viry, které infikují KERNEL32.DLL, se pokusí přepočítat kontrolní součet infikované DLL s použitím Win32 API. Jiné viry rovnou implementují vlastní algoritmus pro korektní přepočítání.

API pro výpočet kontrolního součtu dělá následující12: 1. Vypočítá se suma celého souboru (slovo po slově) a ke slovu se vždy připočte příznak přenosu (carry) jako slovo, například: 0x8a24+0xb400 = 0x13e24 -> 0x3e24 + 0x1 = 0x3e25.

2. Připočte se poslední příznak (pokud existuje).

3. Připočte se velikost souboru (jako DWORD).

W32/Kriz byl prvním virem, který implementoval přepočet kontrolního součtu DLL bez nutnosti volání nějaké systémové API. Je obtížnější nalézt nekonzistenci v souboru, pokud je jeho kontrolní součet korektně vypočítán. Jiné viry jej také přepočítávají, ale pouze v případě, že ten původní je nenulový.

Heuristické skenery první generace nedokážou zachytit takové viry.

6.2.8.1.13 Přejmenování existujících sekcí Některé heuristické skenery první generace se pokouší kontrolovat, zdali během emulace získá řízení nějaká nekódová sekce. Za normální situace některé sekce (jako třeba .reloc, .data atd.) neobsahují vůbec žádný kód (pokud ovšem není soubor zkomprimovaný nějakým run-time pakovačem, který se sekcemi pracuje stejně nestandardním způsobem jako viry). Některé viry mění jméno sekce na náhodný řetězec. Například virus W95/SK přejmenovává sekci .reloc na náhodný pětiznakový řetězec s pravdě-

220

Kapitola 6 – Základní obranné strategie virů

podobností jedna ku osmi. Výsledkem je, že heuristické skenery neumí takový virus (na základě kontroly jména a příznaku sekce) odhalit.

6.2.8.1.14 Omezení infekce hlavičky Heuristika první generace může kontrolovat, jestli vstupní bod programu vede na místo hned za hlavičkami sekcí. W95/Murkry, W95/CIH a velký počet variant viru W95/SillyWR používají metodu infekce hlavičky a mohou být jednoduše detekovatelné heuristickým nebo generickým způsobem. Některé moderní viry pro 32bitové Windows z tohoto důvodu neinfikují PE hlavičku tímto způsobem.

6.2.8.1.15 Omezení importování ordinární hodnotou Pár prvních virů pro Windows a Win32 přepisovalo tabulku importů hostitelského programu tak, aby obsahovala nějaké importy pomocí ordinární hodnoty navíc. To proto, že mnoho hostitelských programů obvykle neimportuje API GetProcAddress() a GetModuleHandle(). Protože je možné importovat pomocí ordinárních hodnot (místo jmen funkcí), viry vloží importy (založené na těchto ordinárních hodnotách) do spustitelného souboru, aby pak mohly tyto Win32 API volání používat. Většina virů pro Win32 ovšem tuto logiku nesleduje, takže heuristika založená na tomto principu je pro takové viry úplně k ničemu.

6.2.8.1.16 Omezení triku CALL-POP Většina virů pro 32bitové Windows, které se připojují na konec hostitele, používá trik s instrukcemi CALL-POP, aby zjistily svoje umístění v paměti a dovedly tak přistupovat ke svým datům. Protože heuristika první generace dokázala tento typ virů velmi snadno najít, autoři virů se snažili najít jiné cesty, pomocí kterých by šlo získat bázovou adresu virového kódu.

Normálně trik vypadá takto: 0040601A E800000000

call 0040601F

; vyzvedni aktuální offset ze zásobníku a ulož jej do registru ESI 0040601F 5E

pop

esi ; ESI=0040601F

Za normální situace kompilátory takový kód nevygenerují, takže sekvence E800000000 se dá považovat za podezřelou. Virus W32/Kriz se snaží výskyt této sekvence omezit, protože pro statickou heuristiku není problém ji najít.

Následující výpis 6.5 ukazuje, jak tento trik implementuje virus W32/Kriz.

Výpis 6.5 Ukrytí techniky CALL-POP. Offset

Operační kód

Instrukce

0040601A

E807000000

call

0040601F

34F4

xor

al,F4

00406021

F0A4

lock

movsb

00406026h

Počítačové viry – analýza útoku a obrana 00406023

288C085E 5EB934AC

sub

[eax+ecx-53CB46A2],cl

0040602A

0200.

add

al,[eax]

221

Instrukce volání na offsetu 0040301A přesměruje vykonávání na instrukci POP ESI (operační kód 5Eh).

V tomto případě je nutné použít dynamickou heuristiku, aby se zjistilo, jestli instrukce CALL skutečně ukazuje na instrukci POP.

6.2.8.1.17 Opravení velikosti kódu v hlavičce Další možnou heuristickou metodou je přepočítání velikosti kódových sekcí, které program používá.

V PE hlavičce je uložena velikost všech kódových sekcí a většina linkerů spočítá příslušnou velikost kódu v programu v závislosti na počtu dat v souboru. Některé viry přidávají do souboru svoji vlastní sekci, ale pak už zapomenou přepočítat údaje v hlavičce a toho dokáže statická heuristika velmi dobře využít.

Bohužel – některé Win32 viry, jako třeba W32/IKX tyto položky přepočítají správně a taková heuristika je v jejich případě neúčinná.

6.2.8.1.18 Nepoužívání API řetězců Tato velmi efektivní obrana proti heuristice a disassemblování se objevuje v řadě moderních virů. Příkladem může být virus W32/Dengue, který nepoužívá žádné řetězce API ze sady Win32. Normálně se API funkce importují s použitím jejich jmen, jako třeba FindFirstFileA(), OpenFile(), ReadFile(), WriteFile() a tak dále. Takto to dělaly viry první generace. Sada podezřelých API řetězců se dá ovšem v nezakódovaných Win32 virech velmi jednoduše postřehnout. Pokud použijeme příkaz strings na těle viru W32/IKX, dostaneme tento výpis: Murkry\ IKX EL32 CreateFileA *.EXE CreateFileMappingA MapViewOfFile CloseHandle FindFirstFileA FindNextFileA FindClose UnmapViewOfFile SetEndOfFile

První řetězec je jméno autora viru Murkry (jména některých autorů virů nebo vulgární slova mohou rovněž dobře posloužit heuristické detekci). Navíc je tam možné spatřit řetězec *.EXE a téměř tucet API pro hledání a modifikaci souborů. To může disassemblování viru velmi usnadnit a také to může být využitelné pro heuristický skener.

222

Kapitola 6 – Základní obranné strategie virů

Moderní viry místo řetězců používají jejich kontrolní součty. Ty se přepočítávají v tabulce exportů jednotlivých DLL knihoven, jako třeba KERNEL32.DLL a podle toho se hledají adresy API. Je obtížnější analyzovat virus, který používá tuto logiku, protože antivirový výzkumník musí identifikovat API, které virus používá a teprve prozkoumáním algoritmu kontrolního součtu viru je možné napsat program, který řetězce API vypíše. Antivirový výzkumník Eugen Kaspersky tuto techniku využívá k identifikaci použitých jmen API, která je velmi rychlá. Navíc Kaspersky vytváří reference pro program IDA, takže se dá rovnou použít v disassembleru13.

Ačkoliv je tato technika velmi užitečná, je specifická pro konkrétní virus a nedá se použít v heuristické analýze kvůli problémům s velkou latencí.

6.2.9 Obrana proti emulaci Heuristická analýza první generace byla specifická pro konkrétní viry. Heuristika kontrolovala jednotlivé možné způsoby infekce pro danou aplikaci. Autoři virů posléze zjistili, že některé skenery používají pro detekci Win32 virů emulaci a začali vymýšlet útoky speciálně zaměřené na tu nejsilnější komponentu skeneru – na emulátor. V této části vám vysvětlím některé techniky obrany proti emulaci, které autoři virů stihli za ta léta vymyslet.

6.2.9.1 Použití instrukcí koprocesoru (FPU) Někteří autoři virů si záhy uvědomili sílu emulátorů, začali v nich hledat slabiny a rychle přišli na to, že v nich není implementována emulace koprocesoru. Většina emulátorů totiž jednoduše přeskakuje instrukce koprocesoru, narozdíl od dnešních procesorů, které je už dlouho standardně podporují.

Viry se nijak neomezují, jakmile závisí na používání instrukcí koprocesoru. Dříve (v 80. letech) autoři virů nemohli koprocesor využívat, protože první procesory neobsahovaly jednotku koprocesoru. Až s příchodem procesorů 486 Intel umístil tuto jednotku do procesoru (systémy 486 SX obsahovaly FPU, které bylo ovšem vypnuto ze dvou důvodů: aby bylo možné prodávat procesory 486 DX s vadnými koprocesory jako typ SX a kvůli redukci nákladů, které by byly potřeba k zavedení "jiných" levnějších procesorů na trh). V dnešní době už má většina systémů schopnost vykonávat instrukce koprocesoru.

Některé nepolymorfní, avšak zakódované viry, už používaly instrukce koprocesoru ke svému dekódování. Prizzy Polymorphic Engine (PPE) byl první, který používal instrukce koprocesoru. PPE je schopný generovat 43 rozdílných instrukcí koprocesoru pro použití v polymorfním decryptoru.

Instrukce koprocesoru musí být samozřejmě podporovány emulátory kódu každého moderního antivirového softwaru.

6.2.9.2 Použití instrukcí MMX Jiní autoři virů šli tak daleko, že implementovali virus, který používá instrukce MMX (MultiMedia eXtension, multimediální rozšíření) na procesorech Pentium. První virus tohoto druhu byl opět W95/ Prizzy. Ten obsahoval příliš velké množství chyb, aby mohl normálně pracovat a žádnému antivirovému výzkumníkovi se nepodařilo namnožit jedinou kopii. Virus dovedl generovat až 46 různých instrukcí MMX.

Počítačové viry – analýza útoku a obrana

223

Jiné úspěšnější viry, jako třeba W32/Legacy14 a W32/Thorin, byly podstatně lépe napsané než jejich předchůdce.

Většina polymorfních motorů, které používají instrukce MMX, nepředpokládá, že má procesor podporu MMX. Některé viry vytvářejí dvě polymorfní decryptovací smyčky a kontrolují přítomnost podpory MMX použitím instrukce CPUID. Virus se může pokusit replikovat na systémech bez podpory MMX, ale to se mu nepovede, pokud nějak nezkontroluje typ procesoru. Instrukce CPUID není dostupná na starších typech procesoru. Není tedy překvapením, že MMX viry často nerozpoznají správně podporu MMX a spustí instrukce MMX na systému, který je neumí vykonat. Výsledkem je vznik výjimky procesoru.

Autoři virů budou moci v blízké budoucnosti odstranit kontrolu přes CPUID, protože množství systémů Pentium s podporou MMX velmi rychle roste.

V roce 2000 se emulace instrukcí MMX stala nutností pro veškerý antivirový software.

6.2.9.3 Použití strukturované obsluhy výjimek (SEH) Použití strukturované obsluhy výjimek ve virech pro Windows je stejně staré jaké první opravdový virus pro Win32. W32/Cabanas používal SEH (Structured Exception Handling) pro účely obrany proti ladění a taky k ochraně před situacemi, které by vedly k pádu procesu. Mnoho virů pro 32bitová Windows nastavuje obsluhu výjimek na svém začátku a automaticky vrací vykonávání hostiteli v případě vzniku nějaké chyby.

Viry často nastavují obsluhu výjimek k vytvoření pasti pro emulátor. Podobný trik obsahuje virus W95/ Champ.5447.B. Navíc – některé polymorfní enginy generují náhodný kód jako součást decryptorů. Po nastavení obsluhy výjimek ji virus nepřímo spustí, čímž se řízení předá jiné části polymorfního decryptoru. Pokud emulátor antivirového programu neumí obsluhovat výjimky, nedostane se během emulace k původnímu kódu viru.

Bohužel – tento problém není záležitostí implementace rozpoznávacího modulu pro obsluhu výjimek.

Ačkoliv se některé podmínky, které vedou ke vzniku výjimky, dají determinovat vcelku jednoduše, emulované prostředí nedovede obsluhovat úplně všechny výjimky bez chyby. Jednoduše není možné stoprocentně zaručit, že dílčí instrukce způsobí generování výjimky15.

Výsledkem je, že virus, který používá náhodné bloky smetí k vyvolání výjimky, nemusí emulátor postřehnout a heuristický skener nemusí pracovat tak, jak by měl (případně nemusí pracovat vůbec).

6.2.9.4 Náhodné spouštění virového kódu: je tohle dnes virus?

Některé viry ve svém vstupním bodu používají past ve formě náhodného spouštění kódu. Tento problém je znám z doby DOSových virů, které svůj kód spouští pouze na základě určitého data nebo času.

Jedním z prvních virů, které tuto techniku používají, byl W95/Invir. Virus buď předá řízení hostitelskému programu (nebo původnímu vstupnímu bodu) nebo vlastnímu virovému tělu. Jinými slovy – spuštění infikovaného programu nezaručuje, že dojde i ke spuštění viru.

224

Kapitola 6 – Základní obranné strategie virů

W95/Invir používá hodnotu FS:[0Ch] jako zdroj náhodnosti. Na systémech Win32, na strojích Intel, je na adrese FS:0 uložen tzv. TIB (Thread Information Block, blok informací threadu). Hodnota WORD na FS:[0Ch] se nazývá W16TDB a má smysl jen pod systémy Windows 9x, na Windows NT bývá tato položka nulová.

Pokud je hodnota 0, virus spustí hostitelský program, čímž se elegantně vyhne svému načtení na systémech Windows NT, protože s nimi není kompatibilní. Položka W16TDB je pod systémy Windows 95 v podstatě náhodná a TIB je přístupný přímo, bez nutnosti volání nějaké API, takže se jedná o jeden z nejjednodušších způsobů, jakým lze získat náhodné číslo.

Základní schéma prvního bloku kódu vypadá následovně: MOV

reg, FS:[0C]

AND

reg, 8

ADD

reg, jumptable

JMP

[reg]

Problém pro emulátory je zřejmý – bez správně nastavené hodnoty na adrese FS:[0Ch] se emulátor nedostane k decryptoru. Jedná se o docela složitou záležitost a detekce takových virů může být krajně obtížná i se zvláštními detekčními metodami – heuristika může takové šikovné viry snadno minout.

6.2.9.5 Použití nedokumentovaných instrukcí procesoru Ačkoliv u procesorů Intel není mnoho nedokumentovaných instrukcí, pár jich tam přece jenom je. Například virus W95/Vulcano používá ve svém polymorfním decryptoru nedokumentovanou instrukci SALC jako smetí, které má zastavit emulátor některých antivirových enginů, které s touto instrukcí nepočítají. Intel praví, že instrukce SALC se má emulovat jako instrukce NOP (no operation). Ovšem na rozdíl od instrukce NOP, která nic nedělá, bude po spuštění této instrukce AL=FFh v případě, že byl nastaven příznak přenosu (CF=1), v opačném případě bude AL vynulováno 16. Implementace těchto instrukcí v emulátoru se může v různých procesorech lehce lišit – tímto způsobem může virus zjistit, zda-li je vykonáván pod emulací.

Emulátory by se tedy neměly zastavovat, pokud narazí na neznámou instrukci. Pokud je ale velikost operačního kódu nesprávně spočítaná, může takový virus uniknout dynamické heuristice.

6.2.9.6 Použití hrubé síly pro dekódování těla viru Některé viry používají ke svému dekódování algoritmus hrubé síly, známý jako RDA (Random Decryption Algorithm, náhodný dekódovací algoritmus). Tuto metodu používaly DOSové viry, jako třeba varianty viru Spanska a některé starší ruské viry, jako třeba rodina RDA. Tyto všechny staré triky autoři virů recyklovali v prostředí Win32. Technika dekódování hrubou silou nepoužívá pevné klíče, ale snaží se uhodnout dešifrovací algoritmus a klíče technikou pokus-omyl. Tato logika je relativně rychlá v případě opravdového spuštění, nicméně při emulaci vyžaduje příliš mnoho iterací, čímž je zaručeno, že tělo viru nebude jednoduše zpřístupněno. Dekódování se dá považovat za podezřelou aktivitu a moderní dynamická heuristika to dovede poznat.

RDA je velmi efektivní útok proti emulátorům kódu, které jsou vestavěny v antivirovém softwaru.

Počítačové viry – analýza útoku a obrana

225

6.2.9.7 Využití multithreadingu Mnoho virů se pokoušelo používat thready pro ztížení práce emulátorů. Emulátory byly prvně navrženy tak, aby emulovaly DOSové aplikace, které jsou jedno-threadové – což je pro emulátory snadnější úkon než emulace multithreadového prostředí. Taková emulace aplikací Windows je velkou výzvou, protože synchronizace různých threadů je klíčová a není vůbec jednoduchá. Jak se emulátory stávají robustnější, autoři virů se zcela jistě pokusí použít tento trik proti emulaci. Některé sofistikované Win32 emulátory, jako třeba ten, který je použitý v norském Norman Antiviru, už dovedou s multithreadovým Win32 kódem efektivně pracovat.

6.2.9.8 Použití přerušení v polymorfních decryptorech Podobně jako některé DOSové viry, několik virů pro Windows 95 používalo náhodné volání přerušení (INT) ve svém polymorfním decryptoru. Některé starší generické decryptory mohou emulaci zastavit, jakmile se zavolá první přerušení. To proto, že většina zakódovaných virů nepoužívá přerušení až do doby, než se kompletně dekódují. Podobný útok používá virus W95/Darkmil, který volá přerušení, jako třeba INT 2Bh, INT 08h, INT 72h atd.

6.2.9.9 Použití API pro předání řízení virovému kódu Virus W95/Kala.7620 byl jedním z prvních virů, který používal API k předání řízení decryptoru. Virus zapíše krátký kus kódu do kódové sekce hostitelské aplikace. Tento krátký kód zavolá API CreateThread() přes tabulku importů hostitele. Adresa začátku threadu je specifikována v poslední sekci hostitele, která je vytvořena samotným virem. Emulátor se ovšem k virovému kódu nedostane, protože skener neumí emulovat API CreateThread(). Moderní antivirový software musí na tuto výzvu reagovat přidáním podpory některých důležitých API. Pro antivirový software je tedy nezbytné mít emulaci API ve svém arzenálu zbraní proti virům.

Během několika posledních let antiviroví výzkumníci očekávali příliv nových virů, které budou používat volání API ve svých polymorfních decryptorech. A dočkali se. Virus W95/Drill byl prvním, který tuto myšlenku implementoval v praxi.

6.2.9.10 Použití dlouhých smyček Počítačové viry se často snaží používat dlouhé smyčky, aby odradily generické decryptory, které používají emulaci. Smyčka bývá často polymorfní, obsahuje kód, který nic nedělá, nicméně v některých případech se velmi dlouhá smyčka používá k vypočítání decryptovacího klíče, který se předá polymorfnímu decryptoru. Příkladem takového viru je W32/Gobi, EPO virus, který používá dlouhé smyčky pro generování klíče, které spustí až 40 miliónů iterací před předáním decryptovacího klíče polymorfnímu decryptoru. Emulace takového virového kódu je extrémně pomalá.

6.2.10 Viry vyhýbající se návnadám Antiviroví výzkumníci obvykle používají nějaké návnady, aby lépe pochopili strategii infekce příslušného viru (více podrobností popisuje kapitola 15). Infikování takových souborů pomáhá při analýze viru, protože se vizuálně velmi snadno oddělí známý obsah souboru od těla viru. Návnady obvykle obsahují

226

Kapitola 6 – Základní obranné strategie virů

nic nedělající instrukce (jako třeba NOPy) a vrací řízení operačnímu systému bez jakékoliv speciální činnosti. Takové soubory se vytvářejí pro různé souborové formáty, mají různé interní struktury (v závislosti na typu viru, který se snaží odchytnout) a obvykle jsou 4, 8, 16 nebo 32 kB velké.

Viry vyhýbající se návnadám používají pro detekci takových souboru různá heuristická pravidla. Virus se například nepokusí infikovat soubor, který je příliš malý, obsahuje velký počet nic nedělajících instrukcí nebo pokud jeho jméno obsahuje nějaká čísla. Takové viry pak spotřebují více času na analýzu.

6.3 Agresivní retroviry Retrovirus je typ počítačového viru, který se snaží obejít nebo vyřadit antivirovou ochranu, osobní firewall nebo jiné bezpečnostní programy z provozu17. Útočník má na výběr mnoho možností, jak toho dosáhnout – většina uživatelů Windows totiž pracuje na svém počítači s právy administrátora. To dává počítačovým virům možnost odstranit procesy a soubory, které patří antivirovému softwaru, z paměti a disku a také možnost tyto programy programově vypnout. Když byl do MS-DOSu poprvé přidán antivirový program MSAV, mnoho virů přišlo s technikami mazání kontrolních souborů na ověřování integrity dat a databází vzorků a také vypínání rezidentní on-access antivirové ochrany18. Rutina na vypínání MSAV/VSAFE (jednoduché volání přerušení se speciálními parametry) byla u virů tak populární, že se stala základní heuristickou technikou pro detekci retrovirů.

Retroviry umí uklidit cestu pro známé viry, které by byly antivirovým software normálně zachyceny.

Autoři takových virů často používají techniky reverzního inženýrství pro vypátrání postupů, kterými lze antivirový software vypnout. Agresivní retroviry dělají po svém spuštění následující činnosti: 

Vypnou nebo odstraní antivirové programy z paměti nebo z disku.



Vypnou nebo obejdou monitory podezřelého chování (behavior-blockers).



Obejdou nebo odstraní osobní firewall.



Vymažou soubory ověřující integritu dat.

 Modifikují soubory ověřující integritu dat (například virus IDEA.6155 od autora Spanska útočí

na soubory ANTI-VIR.DAT programu TBSCAN takovým způsobem, že přepíší první písmeno nezákodovaného názvu souboru daného programu – komponenta pro ověření integrity dat pak soubor nenajde, nepozná, ze soubor byl infikován virem a vypočítá nový kontrolní součet19). 

Vykonají virový kód prostřednictvím antivirového programu (například virus Varicella dovede "utéct", jakmile se program TBCLEAN snaží genericky vyléčit napadený soubor).



Nasadí trojského koně do antivirové databáze. Takové viry se aktivují, jakmile skener začne propátrávat soubory. Například antivirus AVP několikrát čelil takovým útokům – výtvor autora Mr. Sandman nazvaný jako Anti-AVP vkládá novou (hacknutou) databázi do sady databází AVP, aby přinutil antivirový program k detekci viru Boza jako Bizatch (tak se měl virus původně jmenovat). Jiná varianta tohoto útoku přinutí AVP, aby nevyhledával viry a aby během skenování mazal z disku jiné antivirové programy – autor tohoto viru si říkal TCP.



Detekuje spuštění antivirového softwaru a provede nějakou škodu.

Počítačové viry – analýza útoku a obrana

227



Zaútočí proti antivirům takovým způsobem, že učiní bootování obtížnější (příkladem může být virus Ginger, který způsobí zacyklení tabulky rozdělení pevného disku).



Odstraní značky antivirů pro ověřování integrity dat (starší verze programu McAfee SCAN přidávaly na konec spustitelného souboru záznam o integritě dat v souboru, který umí virus Tequila před samotnou infekcí odstranit).



Zaútočí na běžné algoritmy na výpočet kontrolních součtů. Například virus HybrisF autora Vecna útočí na kontrolní součty CRC – tuto techniku před ním vyvinul autor Zhengxi. Kontrolní součty CRC nejsou kryptograficky silné a důkazem toho je virus HybrisF – soubory infikované tímto virem mají stále stejný kontrolní součet CRC, velikost souboru zůstává neměnná. Aplikace pro ověření integrity dat nepoznají rozdíly v infikovaném souboru.



Zabrání infikovaným systémům v připojení a stáhnutí aktuálních antivirových databází (W95/ MTX a W32/Mydoom jsou toho příkladem, jiné retroviry umí i zablokovat přístup k dalším bezpečnostním aktualizacím).



Vyžadují zvláštní ochranu heslem. Například někteří členové rodiny W32/Beagle@mm se posílají v zaheslovaných ZIP archivech, přičemž heslo je náhodně generováno a odesláno v těle e-mailové zprávy. Ačkoliv je prolomení takového archivu hrubou výpočetní silou uskutečnitelné, antivirové programy nemohou tento útok provádět na všech archívech, protože by to vyžadovalo větší množství času. Jako řešení se nabízí použít pro hesla slova z emailové zprávy, nicméně útočník může heslo vložit do obrázku nebo poslat v druhé zprávě. (Tento odstavec jsem napsal pár týdnu předtím, než se objevily některé varianty viru Beagle, které používají Microsoft GDIPLUS API pro převod náhodného hesla do obrázkového souboru, čímž je původní antivirové řešení pokořeno.)



Několik retrovirů neútočí pouze na antivirový software, ale také na nástroje pro analýzu. Viry mohou například zasáhnout proti nástrojům Filemon a Regmon, které se často používají k provedení analýzy dynamického kódu, jak je popsáno v kapitole 15.

Podobné útoky jsou rovněž možné u jiných souborových formátů, jako například u samorozbalujících se archivů nebo u formátů pro dokumenty od Microsoftu. Jakmile je dokument chráněn heslem, makra v dokumentu jsou jím také chráněna. V dřívějších verzích produktů Microsoft Office byla ochrana heslem slabá a antivirový software mohl jednoduše dekódovat makra chráněná heslem a virus najít během pár sekund. Novější verze Microsoft Office používají pro dokumenty silnější ochranu heslem, která dovede odolat známým útokům, a takové dokumenty se pak nedají skenovat. Ačkoliv je ochrana heslem v programu PKZIP prolomitelná, nedá se provést během pár sekund, ale během několika minut a tak antivirové programy nemohou použít hrubou výpočetní sílu, aby takto zaheslované archívy prolomily a mohly je skenovat.

Retroviry jsou obzvlášť velkou výzvou pro antivirový software. Moderní antivirová řešení vyžadují zvláštní ochranu před takovými útoky, jako je třeba rušení procesů, aby se lépe ochránily před neznámými počítačovými viry.

228

Kapitola 6 – Základní obranné strategie virů

Odkazy 1. Vesselin Bontchev, "Future Trends in Virus Writing", Virus Bulletin Conference, 1994, str. 65-82.

2. Andrew Schulman, Raymond J. Michaels, Jim Kyle, Tim Paterson, David Maxey a Ralf Brown, Undocumented DOS, Addison-Wesley, 1990, ISBN: 0-201-57064-5.

3. Peter Szor, "Drill Seeker", Virus Bulletin, leden 2001, str. 8-9.

4. Peter Ferrie, soukromá komunikace, 2003.

5. Gyorgy Ráth, "Copy-Protection on the IBM PC", LSI, Budapešť, 1989, ISBN: 963-592-902-1.

6. Peter Ferrie, osobní komunikace, 2004.

7. Peter Szor, "Coping with Cabanas", Virus Bulletin, listopad 1997, str. 10-12.

8. Dr. Vesselin Bontchev, "Cryptographic and Cryptanalytic Methods Used in Computer Viruses and Anti-Virus Software", RSA Conference, 2004.

9. Peter Szor, "Attacks on Win32 – Part II", Virus Bulletin Conference, září 2000, str. 101-121.

10. Peter Szor, "The Invisible Man", Virus Bulletin, květen 2000, str. 8-9.

11. Igor Daniloff, "New Polymorphic Random Decoding Algorithm in Viruses", EICAR, 1995, str.

9-18.

12. Wason Han, osobní komunikace, 1999.

13. Eugene Kaspersky, osobní komunikace, 1998.

14. Snorre Fageland, "Merry MMXmas!", Virus Bulletin, prosinec 1999, str. 10-11.

15. Kurt Natvig, osobní komunikace, 1999.

16. "Undocumented OpCodes: SALC", http://www.x86.org/secrets/opcodes/salc.htm.

17. Mikko H. Hypponen, "Retroviruses – How Viruses Fight Back", Virus Bulletin Conference, New Jersey, 1994.

18. Yisreal Radai, "The Anti-Viral Software of MS-DOS 6", http://www.virusbtn.com/old/ OtherPapers/MSAV/.

19. Peter Szor, "Bad IDEA", Virus Bulletin, duben 1999, str. 18-19.

KAPITOLA 7 Pokročilé techniky vývoje kódu a generátory počítačových virů "V matematice nemůžete porozumět věcem. Můžete je pouze používat."

– John von Neumann

230

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

V této kapitole se dozvíte o vylepšených obranných technikách, které autoři počítačových virů za dlouhá léta vyvinuli, aby odrazili útok antivirových skenerů.

Podrobně se dozvíte o zakódovaných, oligomorfních, polymorfních1 a vylepšených metamorfních počítačových virech2. Nakonec se podíváme na generátory3 počítačových virů, které používají podobné techniky k vytvoření odlišně vypadajících variant virů.

7.1 Úvod Zde prozkoumáme různé cesty, po kterých se autoři virů za poslední dekádu vydali, aby porazili antivirové skenery. Ačkoliv byla většina těchto technik použita na zamaskování souborových infektorů, můžeme s jistotou očekávat, že se tyto techniky objeví v budoucích počítačových červech.

Za celá ta léta vývoje ušly binární viry velmi dlouhou cestu. Pokud by se někdo vydal po stopách výsledků vývoje virů, došel by k přesvědčení, že takřka všechno myslitelné už bylo učiněno a že se problémy s viry nebudou zvyšovat. Zbývají modely distribuovaných výpočtů, které ještě ve virech spatřeny nebyly.

7.2 Vývoj virového kódu Autoři virů neustále bojují s antivirovými produkty. Jejich největším nepřítelem jsou nejpopulárnější antivirové skenery. Generická antivirová řešení, jako třeba kontrolory integrity dat a monitory blokující podezřelé chování (behavior-blockers) se (narozdíl od nich) nikdy neměla za cíl stát tak populárními.

Ve skutečnosti takové generické modely detekce virů vyžaduji na systémech Windows mnohem větší promyšlení návrhu, protože tyto technologie byly na systémech DOS několikrát překonány DOSovými viry. Výsledkem je, že si mnoho lidí začalo myslet, že tyto techniky jsou k ničemu.

Skenování je řešení, které trh přijal, bez ohledu na jeho nevýhody. Musí tedy čelit rostoucí složitosti a vzrůstajícímu počtu škodlivého softwaru, který se navíc dokáže sám rozšiřovat.

Ačkoliv se moderní výpočetní technika výrazně zrychlila, po dlouhý čas se daly binární kódy virů současnými technikami stěží dohonit. DOSové viry se do roku 1996 vyvíjely do velmi složitých úrovní, od té doby začaly na trhu dominovat 32bitové systémy Windows. Výsledkem bylo, že se autoři virů ve vývoji binárních virů vrátili o několik let zpět. Složitost polymorfismu v DOSu vyvrcholila v roce 1996, když byl představen virus Ply s novým permutačním enginem (metamorfní virus ACG byl představen v roce 1998). Tento vývoj už nicméně nemohl dále pokračovat a tak se pionýři v psaní počítačových virů zaměřili na vyvinutí 32bitových technik pro Win32 platformy.

Někteří autoři virů stále chápou platformu Windows jako příliš složitou, zvlášť v případě systémů Windows NT/2000/XP/2003. Základní techniky infekce už nicméně byly k vidění, nehledě na to, že zdrojové kódy samotných virů byly distribuovány na Internetu. Tyto zdrojové kódy poskytují základy pro masově se šířící červy. Navíc nevyžadují nějaké programátorské zkušenosti – pouze schopnost zkopírovat a vložit text.

V následující části prozkoumáme základní matoucí techniky virového kódu, zakódovanými viry počínaje a moderními metamorfními technikami konče.

Počítačové viry – analýza útoku a obrana

231

7.3 Zakódované viry Už od samého počátku se autoři virů pokoušeli implementovat do kódu virů nějakou evoluci. Jedním z nejjednodušších způsobů k zamaskování fungování virového kódu bylo kódování. Prvním známým virem, který tuto techniku implementoval, byl DOSový Cascade4. Virus začíná neměnným decryptorem, po kterém následuje zakódované tělo viru. Podívejte se na ukázku decryptoru viru Cascade.1701, který je zobrazen ve výpise 7.1.

Výpis 7.1 Decryptor viru Cascade. lea

si, Start

; začátek zakódovaného těla (nastaveno dynamicky)

mov

sp, 0682

; délka zakódovaného těla (1666 bajtů)

xor

[si],si

; první dekódování

xor

[si],sp

; druhé dekódování

inc

si

; inkrementace prvního čítače

dec

sp

; dekrementace druhého

jnz

Decrypt

; smyčka proběhne tolikrát, než se dekódují všechny bajty

Decrypt:

Start:

; Začátek zakódovaného/dekódovaného těla viru

Tento decryptor používá trik proti ladění, protože používá jako jeden z dekódovacích klíčů registr SP (stack pointer, ukazatel na zásobník). Dekóduje se vždy směrem dopředu, registr SI se inkrementuje o jedničku.

Protože registr SI zprvu ukazuje na začátek zakódovaného těla viru, jeho počáteční hodnota závisí na relativní pozici virového těla v souboru. Cascade se připojuje na konec souboru, takže SI bude mít stejnou hodnotu v případě souborů o stejné velikosti. SI (dekryptovací klíč 1) se bude ovšem lišit, pokud mají hostitelské programy různou velikost. Registr SP je prostý čítač počtu bajtů k dekódování – jde tedy směrem dopředu a dekóduje se po slovech (2 bajty), ale místo dekódování se posunuje o jeden bajt. To decryptovací smyčku trochu komplikuje, ale nic nemění na její reverzibilitě. Operace XOR je pro viry velmi praktická, protože "XORování" stejné hodnoty dvakrát vrátí původní hodnotu.

Uvažte kódování písmena P (0x50) klíčem 0x99. Tedy 0x50 XOR 0x99 je 0xC9 a 0xC9 XOR 0x99 vrátí 0x50. Proto mají autoři virů v oblibě tuto techniku zakódování – protože jsou líní! Omezí tak nutnost implementovat dva rozdílné algoritmy, jeden pro zakódování a druhý pro dekódování.

Kryptograficky řečeno – takové kódování je slabé, ačkoliv první antivirové programy měly možnost získat krátký skenovací řetězec ze samotného decryptoru. To ovšem vedlo k několika problémům. Různé viry mohou mít například stejný decryptor, ale kompletně jiné vlastnosti. Detekcí viru podle jeho decryptoru se pak může stát, že antivirus nedovede správně identifikovat příslušnou variantu. A dále – nevirové programy, třeba různé obálky (wrappers) s ochranami proti ladění, mohou mít na začátku svého kódu podobný decryptor. Virus, který používá stejný kód pro svoje dekódování, tak může antivirový program zmást.

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

232

Taková jednoduchá metoda vývoje kódu se záhy objevila i v 32bitových virech pro Windows. W95/Mad a W95/Zombie používají stejnou techniku jako virus Cascade, jediný rozdíl spočívá v 32bitové implementaci. Podívejte se na decryptor z viru W95/Mad.2736 ve výpise 7.2.

Výpis 7.2 Decryptor viru W95/Mad.2736. mov

edi,00403045h

add

edi,ebp

; EDI = začátek ; přidej bázovou adresu

mov

ecx,0A6Bh

; délka zakódované části těla viru

mov

al,[key]

; načti klíč

xor

[edi],al

; dekóduj jeden bajt těla

inc

edi

; inkrementuj místo dekódování

loop

Decrypt

; dekóduj všechny bajty

jmp

Start

; Skoč na Start (přes data)

DB

key

Decrypt:

Start:

86

; proměnný klíč o velikosti jeden bajt ; zakódované/dekódované tělo viru

Jedná se o ještě jednodušší implementaci metody XOR. Detekce takových virů je stále možná bez nutnosti dekódovat tělo viru. Ve většině případů je vzorek kódu decryptoru těchto virů dostatečně unikátní, aby se tyto viry daly podle něj detekovat. Tato detekce sice není exaktní, nicméně stále existuje možnost dekódovat zakódované tělo viru a detekovat i různé varianty. Útočník může implementovat některé speciální techniky, aby proces kódování a dekódování více zkomplikoval a zmátl detekci, popř. léčení zavirovaných souborů antivirovými programy: 

Směr dekódovací smyčky se může měnit, je možné kódovat směrem dopředu i dozadu (viz obrázek 7.1).



Použití vícenásobných vrstev kódování. První decryptor dekóduje druhý, ten dekóduje třetí a tak dále (viz obrázek 7.1c). Viry Hare5 od Demon Emperora, W32/Harrier6 od TechnoRata, {W32,W97M}/Coke od Vecny a W32/Zelly od ValleZe jsou příklady virů, které používají tuto metodu.



Některé decryptovací smyčky získávají řízení jedna po druhé s náhodně zvoleným směrem dekódování. Tato technika kód zpřehází nejvíc (viz obrázek 7.1c).



Existuje pouze jedna decryptovací smyčka, ale používá více než dva klíče k dekódování všech částí informace. V závislosti na implementaci decryptoru mohou být takové viry mnohem obtížněji detekovatelné. Dost záleží na velikosti klíče – čím je klíč větší (8, 16, 32 bitů nebo ještě více), tím déle bude dekódování hrubou výpočetní silou trvat (v případě, že klíče nemohou být jednoduše z viru vyextrahovány).

Počítačové viry – analýza útoku a obrana

233

Obrázek 7.1 Příklady dekódovacích smyček.   Začátek decryptoru je utajen. Mezi decryptorem a zakódovaným tělem nebo zakódovaným

tělem a koncem souboru jsou umístěny náhodné bajty. 

Použije se nelineární dekódování. Některé viry, jako třeba W95/Fono používá jednoduchý nelineární algoritmus s tabulkou klíčů. Kódování viru je založeno na substituční tabulce, virus se například rozhodne nahradit písmena A za Z, P za L atd., takže takové slovo APPLE bude po takovém zakódování vypadat jako ZLLPE. Protože dekódování viru není lineární, virové tělo se nedekóduje bajt po bajtu. To může jednoduše oklamat virové analytiky-začátečníky, protože virus nemusí vypadat, že je zakódovaný.

Pokud se potom použije některý řetězec pro detekci viru, bude detekce fungovat jen částečně.

Tato technika dovede přelstít i vylepšené techniky detekce, které používají emulátor. Ačkoliv by v normálním případě emulace pokračovala tak dlouho, dokud by se nenarazilo na lineární dekódování, za což se může považovat postupná změna bajtů v paměti virtuálního stroje skeneru, bude emulace pokračovat dál, dokud se nenarazí na limit.

Varianta viru W32/Chiton ("Efish") používá podobnou metodu jako Fono, ale vždy se ujistí, že je každý bajt těla viru nahrazen jiným bajtem použitím kompletní substituční tabulky. Chiton navíc pro každý bajt kódu používá různé hodnoty, což znatelně komplikuje proces dekódování.

Viry jako třeba W95/Drill a {W32,Linux}/Simile.D reprezentují vrchol umění nelineárního zakódování, kde se dekóduje tělo viru v pseudonáhodném pořadí a každé místo v kódu se dekóduje jen jednou7.



Útočník se může rozhodnout neukládat kódovací klíč a místo toho se pokusí ke svému dekódování použít hrubou sílu, pomocí které získá kódovací klíče po svém. Takové viry používající RDA techniky (Random Decryption Algorithm, náhodný dekódovací algoritmus) jsou mnohem hůře detekovatelné. Příkladem viru, který používá takovou techniku, je RDA.Fighter.



Útočník může použít silný algoritmus pro zakódování těla viru. Rodina viru IDEA napsaná autorem, který si říká Spanska, využívá tuto metodu. Jeden z několika decryptorů používá šifru IDEA8. Protože virus sebou nese dekódovací klíč, zakódování se nedá považovat za silné, avšak

234

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ... léčení takto napadnutých souborů je problém, protože antivirové programy musí implementovat kódovací algoritmus, který si s použitým zakódováním poradí. Druhá dekódovací vrstva viru IDEA9 navíc používá RDA.



Český virus W32/Crypto od Prizzyho demonstroval použití Microsoft Crypto API v počítačových virech. Crypto za běhu kódoval DLL knihovny na infikovaném systému s použitím dvojice klíčů (soukromý a veřejný klíč). Jiné počítačové červy a backdoory (tzv. zadní vrátka) také používají Crypto API k dekódování zakódovaného obsahu, což činí práci antivirových skenerů obtížnější. Příkladem počítačového červa, který používá Crypto API, je například W32/Qint@mm, který zakódovává EXE soubory.



Samotný decryptor někdy není součástí viru. Viry jako třeba W95/Resur10 a W95/Silcer jsou představiteli této metody. Tyto viry donutí zavaděč systému Windows k přesunutí (relocate) infikovaných modulů, jakmile se načítají do paměti. Samotná relokace modulu je zodpovědná za dekódování virového těla, protože do něj virus vložil speciální relokační záznamy. Bázová adresa spustitelného modulu v tomto případě funguje jako kódovací klíč.



Virus Cheeba demonstroval, jak může být kódovací klíč uložen mimo tělo viru. Cheeba byl vypuštěn v roce 1991 a jeho tzv. payload (aktivační rutina viru) se zakóduje jménem souboru a dekóduje se správně pouze tehdy, když virus přistupuje k souboru11. Pokud není šifra viru slabá, antiviroví výzkumníci jednoduše nemohou popsat payload viru. Dmitry Gryaznov zredukoval (s použitím kryptoanalýzy těla viru) velikost klíče potřebného k útoku na šifru Cheeby na pouhých 2150400 možných klíčů, za předpokladu, že zašifrovaný kód je napsaný podobným stylem jako zbytek kódu viru12. Výsledkem bylo nalezení správného jména souboru – "user.bss".

Tento soubor patřil k populárnímu softwaru pro BBS. Je pravděpodobné, že se časem objeví více takových triků (tzv. "clueless agents"13), které znesnadní získávání znalostí o daném nebezpečí, které hrozí ze strany útočníka.



Kódovací klíče mohou být generovány různými způsoby, např. konstantně, náhodně, fixně, s posunutím atd.



Samotný klíč může být uložen v decryptoru, v hostiteli nebo nikde. V některých případech kód decryptoru funguje jako dekódovací klíč, což může způsobovat problémy tehdy, pokud debugger nějak poškodil decryptor. Tato technika může rovněž posloužit jako útok na emulátory, které používají techniky optimalizace kódu pro efektivnější běh decryptorů (příkladem takového viru je například Tequila).



Náhodnost klíče je také důležitým faktorem. Některé viry generují nové klíče pouze jednou za den a označují se jako pomalé generátory. Jiní dávají přednost generování klíčů pokaždé, když infikují soubor – ty se označují jako rychlé generátory. Útočník může k dosažení náhodnosti použít mnoho různých metod. Jednoduché příklady zahrnují časovač nebo datum a čas uložený v CMOS a CRC32. Složitějším příkladem je generátor pseudonáhodných čísel Mersenne Twister14 použitý ve virech W32/Chiton a W32/Beagle.



Útočník může označit některá místa jako místa určená dekódování zakódovaného obsahu. Nejčastější metody jsou zobrazeny na obrázku 7.2.

Počítačové viry – analýza útoku a obrana

235

Obrázek 7.2 Možná místa pro dekódování. A) Decryptor dekóduje data na místě zakódovaného těla viru. Tato metoda je nejběžnější, zakódovaná data musí být ovšem v paměti zapisovatelná, což je věc konkrétního operačního systému. B) Decryptor čte zakódovaný obsah a buduje dekódované tělo viru na zásobníku. To je pro útočníka velmi praktické, protože je zásobník zapisovatelný automaticky. C) Virus alokuje paměť pro dekódované tělo a data. To může být určitá nevýhoda, protože útočník potřebuje před samotným dekódováním prvně alokovat paměť.

Poznámka Některé metamorfní viry, jako třeba Simile, tuto nevýhodu vyřešily tak, že kód viru, který se stará o alokaci paměti, je dostatečně variabilní na to, aby se z něj dal vybrat vyhledávací řetězec.

Předchozí techniky fungují velmi efektivně, když se zkombinují s variabilními decryptory, které se postarají o změny v nových generacích viru. V následujících částech jsou probrány oligomorfní a polymorfní decryptory, které se ve virech používají.

7.4 Oligomorfní viry Autoři virů velmi rychle přišli na to, že se detekce zakódovaných virů pro antivirový software odvíjí od toho, jak dlouhý a jedinečný je samotný decryptor. Aby antivirové produkty překonali, rozhodli se implementovat techniky, které umí vytvářet mutované decryptory.

Narozdíl od zakódovaných virů ty oligomorfní mění v nových generacích svůj decryptor. Nejjednodušší technikou ke změně decryptorů je použití více decryptorů namísto jednoho. Prvním takovým známým virem byl Whale, který si sebou nesl pár tuctů rozdílných decryptorů, přičemž si vždy jeden z nich náhodně vybral.

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

236

W95/Memorial měl schopnost vystavět až 96 různých decryptorů. Proto byla detekce viru, která byla založena na hledání kódu decryptoru, nepraktickým, ačkoliv stále použitelným řešením. Většina antivirových produktů se pokusila tento problém řešit dynamickým dekódováním zakódovaného těla, čímž byla ovšem detekce stále založena na konstantním kódu dekódovaného těla viru.

Podívejte se na příklad z viru Memorial zobrazený ve výpisu 7.3, jedná se o jeden z 96ti možných případů decryptoru.

Výpis 7.3 Příklad decryptoru viru W95/Memorial. mov

ebp,00405000h

; načti bázi

mov

ecx,0550h

; počet bajtů

lea

esi,[ebp+0000002E]

; offset "Start"

add

ecx,[ebp+00000029]

; plus tento počet bajtů

mov

al,[ebp+0000002D]

; vyber první klíč

Decrypt: nop

; smetí

nop

; smetí

xor

[esi],al

; dekóduj bajt

inc

esi

; přesuň ukazatel na další

inc

al

; posuň klíč

dec

ecx

; jsou tam nějaké další bajty k dekódování?

jnz

Decrypt

; skákej, dokud nejsou všechny bajty dekódované

jmp

Start

; dekódování u konce, spusť tělo

nop

; smetí

; datová oblast Start: ; zakódované/dekódované tělo viru

Povšimněte si posunu klíče. Pořadí instrukcí může být lehce měněno a decryptor může pro smyčku používat odlišné instrukce.

Porovnejte tento příklad s jiným decryptorem z výpisu 7.4.

Výpis 7.4 Lehce odlišný decryptor viru W95/Memorial. mov

ecx,0550h

; počet bajtů

mov

ebp,013BC000h

; načti bázi

lea

esi,[ebp+0000002E]

; offset"Start"

add

ecx,[ebp+00000029]

; plus tento počet bajtů

mov

al,[ebp+0000002D]

; vyber první klíč

Decrypt: nop

; smetí

Počítačové viry – analýza útoku a obrana nop

237

; smetí

xor

[esi],al

; dekóduj bajt

inc

esi

; přesuň ukazatel na další bajt

inc

al

; posuň klíč

loop

Decrypt

; skákej dokud nejsou všechny bajty dekódované

jmp

Start

; dekódování u konce, spusť tělo

nop

; smetí

; datová oblast Start: ;

zakódované/dekódované tělo viru

Všimněte si výskytu instrukce "loop" a prohození instrukcí na začátku decryptoru. Virus je oligomorfní tehdy, pokud je schopný měnit svůj decryptor (v omezeném rozsahu).

Je zajímavé, že některé produkty, které jsme testovali, nebyly schopny zachytit všechny instance viru Memorial. To proto, že pro nalezení a pochopení generátoru oligomorfního decryptoru je potřeba prozkoumat takové viry do nejmenších detailů. Bez patřičné ruční analýzy se nedají pomalé oligomorfní viry spolehlivě detekovat. Například decryptor viru Badboy15 se mění po jedné instrukci – a velmi mimořádně. Jedná se o velkou výzvu pro centra zabývající se automatickou analýzou virů.

Jiným příkladem oligomorfních virů je ruská rodina virů nazvaná jako WordSwap.

7.5 Polymorfní viry Dalším krokem v úrovni obtížnosti je polymorfní útok. Polymorfní viry umějí měnit svůj decryptor do vysokého počtu odlišných instancí, které mohou mít až milióny různých forem.

7.5.1 Virus 1260 Prvním známým polymorfním virem byl virus 1260, který byl naprogramován ve Spojených Státech Markem Washburnem v roce 199016. Tento virus používal mnoho zajímavých technik, jejichž příchod už dříve předpověděl Fred Cohen. Virus používal k dekódování svého těla dva posunující se klíče, a co je ještě důležitější – vkládal nepotřebné instrukce do svého decryptoru. Tyto instrukce jsou v podstatě obyčejným "smetím" a nemají jinou funkci než vytvoření variabilnějšího decryptoru.

Antivirové skenery byly virem 1260 poraženy, protože nebylo možné najít jednoznačný řetězec, podle kterého by bylo možné virus detekovat. Ačkoliv je decryptor viru 1260 velmi jednoduchý, může se zvětšovat a zmenšovat v závislosti na množství vložených nepotřebných instrukcí a náhodného zarovnání na konci decryptoru až po 39 bajtů smetí. Navíc každá skupina instrukcí (prolog, dekódování a inkrementace) vně decryptoru může být obměňována v libovolném pořadí. Kostra decryptoru se tedy může měnit.

Podívejte se na příklad jedné instance decryptoru vyextrahovaného z viru 1260 (viz výpis 7.5).

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

238 Výpis 7.5

Příklad decryptoru viru 1260. ; Skupina 1 – Instrukce prologu inc

si

; volitelné, náhodné smetí

mov

ax,0E9B

; nastav klíč 1

di,012A

; offset "Start"

clc

; volitelné, náhodné smetí

mov nop

; volitelné, náhodné smetí

mov

cx,0571

; počet bajtů – klíč 2

; Skupina 2 – Dekódovací instrukce Decrypt: xor

[di],cx

; dekóduj první slovo klíčem 2

sub

bx,dx

; volitelné, náhodné smetí

xor

bx,cx

; volitelné, náhodné smetí

sub

bx,ax

; volitelné, náhodné smetí

sub

bx,cx

; volitelné, náhodné smetí

nop

; nevolitelné smetí

xor

dx,cx

; volitelné, náhodné smetí

xor

[di],ax

; dekóduj první slovo klíčem 1

; Skupina 3 – Dekódovací instrukce inc

di

; další bajt

nop

; nevolitelné smetí

clc

; volitelné, náhodné smetí

inc

ax

; posuň klíč 1

; smyčka loop

Decrypt

; skákej, dokud nejsou všechny bajty dekódovány – ; posuň klíč 2 ; náhodné zarovnání až do 39 bajtů

Start: ;

zakódované/dekódované tělo viru

V každé skupině instrukcí je umístěno až 5 instrukcí smetí (INC SI, CLC, NOP a další, nic nedělající instrukce) bez opakování. Jsou tam vždy dvě instrukce smetí NOP. 1260 nezvládá nahrazování registrů, ale složitější polymorfní útoky tento trik používají. Virus 1260 má nicméně efektivní polymorfní engine, který umí generovat vysoký počet rozličných decryptorů.

7.5.2 Dark Avengerův mutovací engine (MtE) Dalším důležitým milníkem v historii vývoje polymorfních virů byl MtE17, mutační engine napsaný Dark Avengerem z Bulharska. První verze MtE byla vypuštěna během léta roku 1991, druhá následovala

Počítačové viry – analýza útoku a obrana

239

počátkem roku 1992. Myšlenka mutovacího enginu byla založena na modulárním vývoji. Pro nováčky bylo obtížné napsat polymorfní virus, a proto jim chtěli schopnější autoři pomoci. Motor MtE byl vypuštěn jako objekt, který se dá připojit k libovolnému viru.

MtE je navržen jako volání funkce mutovacího enginu, kdy se předávají parametry v předdefinovaných registrech. Engine se pak už sám postará o vybudování polymorfní obálky nad virem.

Parametry enginu zahrnují následující: 

Pracovní segment.



Ukazatel na kód, který se má zakódovat.



Délku těla viru.



Báze decryptoru.



Adresu vstupního bodu hostitele.



Cílové umístění zakódovaného těla.



Velikost decryptoru (drobný, malý, střední nebo velký).



Bitové pole registrů, které se nemají používat.

Výstupem MtE je polymorfní dekódovací rutina se zakódovaným tělem viru umístěným v zadaném bufferu (viz výpis 7.6).

Výpis 7.6 Příklad decryptoru vygenerovaného pomocí MtE. mov

bp,A16C

; Tento blok inicializuje registr BP

mov

cl,03

; (delta je v tomto případě 0x0D2B)

ror

bp,cl

mov

cx,bp

mov

bp,856E

or

bp,740F

mov

si,bp

mov

bp,3B92

add

bp,si

xor

bp,cx

sub

bp,B10C

; na "Start"-delta

; Tak, registr BP je konečně inicializován, ; ovšem dále obsahuje matoucí ukazatel ; na zakódované tělo

Decrypt: mov

bx,[bp+0D2B] ; vyber další záznam

add

bx,9D64

xchg

[bp+0D2B],bx ; ulož dekódovanou hodnotu na místo

; (poprvé na"Start") ; dekóduj ho

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

240 mov

bx,8F31

; inkrementuj BP o 2

sub

bx,bp

mov

bp,8F33

sub

bp,bx

; a oprav délku

jnz

Decrypt

; jsou už všechny bajty dekódované?

Start: ; zakódované/dekódované tělo viru

Tento příklad demonstruje, jak je takový engine komplikovaný. Přišli byste na to, jak jej detekovat?

Zdá se být logické, abychom se prvně pokusili shromáždit dostatečně velké množství vzorků. Poprvé mi to trvalo celkem 5 dní, než jsem byl schopen pro něj napsat spolehlivý detektor. MtE dovedlo produkovat některé decryptory, které se objevily jen v 5% (nebo ještě méně) případech. Engine měl nicméně několik malých omezení, které umožnily (s pomocí disassembleru délky instrukcí a stavového stroje) virus spolehlivě detekovat. Ve skutečnosti existuje pouze jeden jediný konstantní bajt v MtE decryptoru, a to 0x75 (JNZ), který je následován záporných offsetem – i tento skok je umístěný na variabilním místě (na konci decryptoru, jehož délka není konstantní).

Poznámka MtE nepoužívá v decryptoru instrukce smetí, jako to dělá například virus 1260. MtE tedy útočí na techniky, které se snaží optimalizovat decryptory, aby překonaly polymorfismus.

Dopad MtE na antivirový software byl jasný – většina enginů antivirových programů musela projít bolestivým přeprogramováním a nutností implementovat ve skenovacím enginu virtuální stroj. Jak pravil Frans Veldman, "prostě necháme virus, aby odvedl špinavou práci za nás."

Po MtE rychle přišly další podobné enginy, jako třeba TPE (Trident Polymorphic Engine), který vytvořil Masouf Khafir v Holandsku v roce 1993.

V dnešní době jsou známy stovky polymorfních enginů. Většina z nich byla použita k vytvoření pouze několika virů. Jakmile lze detekovat polymorfní decryptor, jeho další používání se stává nevýhodou, protože další nové viry se dají zachytit stejnou detekcí. Taková detekce ovšem sebou nese jistá úskalí ve formě falešných poplachů. Spolehlivější techniky detekce spočívají v rozpoznání samotného těla viru.

To umožňuje autorům virů úspěšně používat stejné polymorfní enginy pro různé viry – až do doby, než budou takové viry odhalitelné heuristickými nebo generickými metodami detekce.

7.5.3 32bitové polymorfní viry W95/HPS a W95/Marburg18 byly prvními viry, které začaly používat 32bitové polymorfní enginy. Tyto dva viry byly vytvořeny známým španělským autorem virů, který si říkal GriYo, a to v roce 1998. Ten také vytvořil vysoce polymorfní viry pro DOS, jako třeba virus Implant19.

Počítačové viry – analýza útoku a obrana

241

Stejně jako polymorfní engine Implantu je i engine viru HPS velmi výkonný a vyspělý. Podporuje subrutiny s použitím instrukcí CALL/RET a podmíněné skoky s nenulovým offsetem. Kód polymorfního enginu zabírá zhruba polovinu kódu viru a mezi vygenerované bloky decryptoru se umisťují náhodné bajty dat. Celý decryptor se vybuduje pouze během fáze inicializace viru, čímž je zajištěn pomalý polymorfismus, což znamená, že antiviroví výzkumníci nemohou efektivně testovat detekční spolehlivost skenerů, protože musí infikované PC vždy restartovat, aby jim virus vytvořil nový decryptor.

Decryptor se skládá z instrukcí procesoru Intel 386. Tělo viru je zakódováno a dekódováno různými metodami, včetně instrukcí XOR/NOT a INC/DEC/SUB/ADD s 8, 16 nebo 32bitovými klíči. Z pohledu detekce toto drasticky snižuje použitelné možnosti. Bohužel musím uznat, že tento polymorfní engine je velmi dobře napsaný, stejně jako zbytek viru a zjevně nebyl vytvořen nějakým začátečníkem.

Třeba následující příklad decryptoru, který jsem pro názornost zjednodušil. Polymorfní decryptor viru je umístěn za variabilně zakódovaným tělem viru. Decryptor je rozdělený na dva menší ostrůvky kódu, které se mohou objevit v promíchaném pořadí. V příkladu ve výpisu 7.7 decryptor začíná na návěští Decryptor_Start a dekódování pokračuje až do doby, než kód konečně skočí na dekódované tělo viru.

Výpis 7.7 Ukázka dekryptoru viru W95/Marburg.

Start: ; zde je umístěné zakódované/dekódované tělo viru Routine-6: dec

esi

; dekrementuj čítač smyčky

ret Routine-3: mov

esi,439FE661h

; nastav čítač smyčky v ESI

ret Routine-4: xor

byte ptr [edi],6F

; dekóduj konstantním bajtem

ret Routine-5: add

edi,0001h

; posuň ukazatel dekódovaní na další bajt

ret Decryptor_Start: call

Routine-1

; nastav EDI na "Start"

call

Routine-3

; nastav čítač smyčky

Decrypt: call

Routine-4

; dekóduj

call

Routine-5

; přejdi na další bajt

call

Routine-6

; dekrementuj čítač smyčky

cmp

esi,439FD271h

; je už všechno dekódované?

jnz

Decrypt

; ještě ne, pokračuj v dekódování

jmp

Start

; skoč na dekódovaný začátek viru

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

242 Routine-1: call

Routine-2

; trik CALL-POP!

Routine-2: pop

edi

sub

edi,143Ah

; EDI ukazuje na"Start"

ret

Předchozí decryptor je vysoce strukturovaný a každý jeho funkční celek je umístěn ve speciální rutině.

Výsledkem jsou miliony možných vzorků kódu s náhodnými daty mezi ostrůvky.

Polymorfní viry mohou vytvořit bezpočet nových decryptorů, které používají různé metody pro zakódování konstantních částí virového těla (kromě svých datových oblastí).

Některé polymorfní viry, jako třeba W32/Coke používají vícenásobné vrstvy zakódování. Varianta Coke dokonce umí polymorfně infikovat dokumenty Microsoft Wordu. Coke mění své makro (prostřednictvím svého binárního kódu) přímo, místo používání samotných maker. Normálně jsou polymorfní makro viry velmi pomalé, protože vyžadují mnoho interpretací (interpretation). Protože Coke generuje změněná makra pomocí svého binárního kódu, nepotýká se s žádným zpomalováním počítače a jeho přítomnost je tedy hůře rozpoznatelná. Podívejte se na následující příklad viru Coke, které jsem vybral ze dvou instancí změněného makra AutoClose() ve výpisu 7.8.

Výpis 7.8 Krátký příklad polymorfního makra viru Coke.

‘BsbK Sub AuTOclOSE() oN ERROr REsuMe NeXT SHOWviSuAlBASIcEditOr = faLsE If nmnGG > WYff Then For XgfqLwDTT = 70 To 5 JhGPTT = 64 KjfLL = 34 If qqSsKWW < vMmm Then For QpMM = 56 To 7 If qtWQHU = PCYKWvQQ Then If lXYnNrr > mxTwjWW Then End If If FFnfrjj > GHgpE Then End If

Druhý příklad je trochu delší (kvůli zanesenému smetí). V příkladu jsem vyznačil některé podstatné instrukce – povšimněte si, že ani ty nejsou zobrazeny ve stejném pořadí. Předchozí instance viru například vypíná Visual Basic Editor, takže už jej v menu Wordu nespatříte. Ve výpisu 7.9 se toto odehraje taky, ale až za hromadou vloženého smetí a jiných instrukcí.

Počítačové viry – analýza útoku a obrana

243

Výpis 7.9 Další příklad polymorfního makra viru Coke. ‘fYJm Sub AUtOcLOse() oN ERRor REsUME NexT optIOns.saVenorMALPrOmpT = FAlsE DdXLwjjVlQxU$ = "TmDKK" NrCyxbahfPtt$ = "fnMM" If MKbyqtt > mHba Then If JluVV > mkpSS Then jMJFFXkTfgMM$ = "DmJcc" For VPQjTT = 42 To 4 If PGNwygui = bMVrr Then dJTkQi = 07 ‘wcHpsxllwuCC End If Next VPQjTT quYY = 83 End If DsSS = 82 bFVpp = 60 End If tCQFv=1 Rem kJPpjNNGQCVpjj LyBDXXXGnWW$ = "wPyTdle" If cnkCvCww > FupJLQSS Then VbBCCcxKWxww$ = "Ybrr" End If opTiONS.COnFIrmCOnvErsiOnS = faLSe Svye = 55 PgHKfiVXuff$ = "rHKVMdd" ShOwVisUALbaSiCEdITOR = fALSe

Novější polymorfní enginy používají decryptor založený na RDA, který implementuje útok hrubou výpočetní silou proti svému konstantnímu, avšak variabilně zakódovanému tělu. Ruční analýza takových virů může vést k velkým překvapením. Často v nich lze nalézt neefektivitu v náhodnosti generovaných algoritmů, která se dá zneužít k protiútoku. Někdy může dokonce jeden jediný "wildcard" řetězec zajistit perfektní detekci.

Většina skenerů měla už před léty emulátor kódu, který uměl emulovat 32bitové PE soubory. Jiní antiviroví výzkumníci pouze implementovali dynamické dekódování, aby si s takovými viry poradili. To

244

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

fungovalo v předchozích případech, protože tělo viru bylo po dekódování konstantní. Jak vyplývá z různých AV testů, někteří dodavatelé stále nemají podporu detekce složitějších virů.

Autoři virů použili kombinaci technik zatajení vstupního bodu s 32bitovým polymorfismem, aby učinili práci antivirových skenerů ještě obtížnější. Navíc se pokusili implementovat techniky obrany proti emulaci, aby vyřadili emulátory kódu z provozu.

Všechny polymorfní viry si nicméně stále sebou nesou konstantní kód svého těla, které je možné pomocí mnoha vylepšených technik dekódovat a identifikovat. Pro názornost se podívejte na obrázek 7.3.

Obrázek 7.3

Instance zakódovaných a dekódovaných těl polymorfního viru.

7.6 Metamorfní viry Autoři virů stále tráví týdny a měsíce vytvářením nových polymorfních virů, které díky svým chybám v kódu nemají šanci se dále rozšířit. A na druhou stranu – antiviroví výzkumníci jsou schopni si s detekcí takových virů poradit během několika minut nebo dnů, za což může nízký existující počet efektivních polymorfních enginů.

Samozřejmě, že se autoři virů snaží implementovat různé nové techniky vývoje kódu, aby práci výzkumníkům co nejvíce ztížili. W32/Apparition byl prvním známým 32bitovým virem, který ke svému vývoji v dalších generacích nepoužíval polymorfní decryptory. Virus si v sobě nese zdrojový kód a vypustí jej kdykoliv, když najde na počítači nějaký nainstalovaný kompilátor. Virus vkládá a odebírá ze svého zdrojového kódu smetí a znovu se rekompiluje. Tímto způsobem se virus v dalších generacích naprosto liší od předešlých. Je jen náhoda, že se W32/Apparition nestal velkým problémem. A taková technika by

Počítačové viry – analýza útoku a obrana

245

byla mnohem více nebezpečnější, kdyby byla implementovaná ve formě Win32 červa. A ještě mnohem nebezpečnější by byla implementace na platformách typu Linux, kde jsou kompilátory jazyka C v mnoha případech standardně instalovány i na systémech, které se nepoužívají pro vývoj. Navíc se už objevily MSIL (Microsoft Intermediate Language) viry, které se umí přebudovat s pomocí jmenného prostoru Systém.Reflection.Emit a implementovat tak permutační engine. Příkladem takového metamorfního enginu je virus MSIL/Gastropod, který napsal autor Whale.

Technika W32/Apparition není překvapením. Je jednodušší vybudovat kód ze zdrojového formátu než z kódu binárního. A proto různé skriptovací a makro viry používají vkládání instrukcí smetí a jejich následné odstraňování, aby dosáhly dalšího vývoje v nových generacích20.

7.6.1 Co je metamorfní virus?

Igor Muttik vysvětlil podstatu metamorfních viru v této krátké větě: "Metamorfismus je polymorfismus těla". Metamorfní viry nemají ani decryptor, ani konstantní tělo viru, ale jsou schopné vytvářet nové generace, které vypadají odlišně. Nepoužívají žádné datové oblasti vyplněné konstantním řetězcem, celé tělo mají ve formě kódu, ve kterém jsou uložená i data.

Materiální metamorfóza existuje i v reálném životě. Například – takové polymery tvarové paměti mají schopnost se transformovat zpět do svého původního tvaru v okamžiku, kdy se zahřejí21. Metamorfní počítačové viry umí měnit svůj tvar z jedné formy na druhou, ale obvykle se snaží generovat instance, které jsou velmi blízké té původní.

Obrázek 7.4 znázorňuje více tvarů těla metamorfních virů.

Obrázek 7.4

Tělo metamorfního viru se mění v průběhu dalších generací.

246

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

Ačkoliv existují nějaké DOSové metamorfní viry, jako třeba ACG (Amazing Code Generator), nestaly se znatelným problémem pro koncové uživatele. Dnes existuje více metamorfních virů pro Windows než pro DOS. Jediným rozdílem mezi těmito viry je jejich šířící potenciál – síťové prostředí dává metamorfním červům větší schopnost páchat velké škody.

7.6.2 Jednoduché metamorfní viry V prosinci roku 1998 vytvořil Vecna (známý autor virů) virus W95/Regswap. Regswap implementuje metamorfismus přes změnu v použití registrů. Každá část těla viru bude používat jiné registry, avšak stejný kód. Složitost takového viru není příliš velká. Výpis 7.10 ukazuje názorný kód, který byl získán ze dvou generací viru W95/Regswap, které používají odlišné registry.

Výpis 7.10 Dvě různé generace viru W95/Regswap. a.)

5A

pop

edx

04000000 BF04000000

mov

edi,0004h

8BF5 8B

mov

esi,ebp

0C000000 B80C000000

mov

eax,000Ch

81C288000000 81 88000000

add

edx,0088h

8B1A 8B

mov

ebx,[edx]

899C8618110000 89 18110000

mov

[esi+eax*4+00001118],ebx

b.)

58

pop

eax

04000000 BB04000000

mov

ebx,0004h

8BD5 8B

mov

edx,ebp

0C000000 BF0C000000

mov

edi,000Ch

81C088000000 81 88000000

add

eax,0088h

8B30 8B

mov

esi,[eax]

89B4BA18110000 89 18110000

mov

[edx+edi*4+00001118],esi

Tučně vyznačené oblasti zobrazují společné oblasti obou generací. K detekci takového viru tedy můžeme použít "wildcard" řetězec. Navíc podpora půlbajtových "wildcard" řetězců (označené jako ?), jako třeba 5? B? (jak popsal Frans Veldman) povede k ještě přesnější detekci. Použitím řetězce 5?B? budeme moci detekovat kódy jako třeba 5ABF, 58BB atd.

V závislosti na aktuálních schopnostech skenovacího enginu bude ovšem takový virus vyžadovat algoritmickou detekci kvůli chybějící podpoře vyhledávacích "wildcard" řetězců. Pokud není algoritmická detekce k dispozici v nějaké aktualizaci antivirové databáze, vydání nové verze antivirového produktu se může protáhnout o několik týdnů i měsíců – pro všechny platformy!

Počítačové viry – analýza útoku a obrana

247

Další autoři virů se snažili předělat starší permutační techniky. Například virus W32/Ghost umí přeuspořádat svoje subrutiny podobným způsobem, jako to dělá DOSová rodina virů BadBoy (viz obrázek 7.5). BadBoy vždy začíná ve vstupním bodě viru.

Obrázek 7.5

Virus Badboy používá 8 modulů.

Pořadí subrutin bude rozdílné z generace na generaci, což povede k n! různým generacím virů, kde n je počet subrutin. BadBoy jich má 8, takže 8! = 40320 různých generací. W32/Ghost (objevený v květnu 2000) má 10 funkcí, takže 10! = 3628800 kombinací. Oba viry se dají detekovat vyhledávacími řetězci, nicméně některé skenery musí použít algoritmickou detekci.

V lednu roku 2000 se objevily dvě různé varianty viru W95/Zmorph. Polymorfní engine viru implementuje vývoj kódu typu vybuduj-a-spusť. Virus se přestaví (rebuild) na zásobníku pomocí push instrukcí, přičemž budovací rutina viru je už metamorfní. Engine podporuje vkládání a odstraňování instrukcí skoku mezi libovolnými instrukcemi vybudovaného kódu. Emulátory kódu si nicméně s takovými viry umí jednoduše poradit. Konstantní oblast kódu viru je užitečná pro přesnou identifikaci, protože tělo viru je dekódováno na zásobníku.

7.6.3 Složitější metamorfní viry a permutační techniky V červenci roku 2000 se objevil virus W32/Evol. Tento virus používá metamorfní engine a dovede běžet na všech hlavních platformách Win32. Výpis 7.11 (sekce a.) ilustruje příklad kusu kódu změněného v sekci b. do nové podoby. Dokonce i magické DWORD hodnoty (5500000Fh, 5151EC8Bh) se mění v každé nové generaci viru, jak je to vidět v sekci c. Žádný "wildcard" řetězec se tedy nedá k detekci tohoto viru použít. Engine viru W32/Evol umí rovněž vkládat smetí mezi jednotlivé instrukce.

248

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

Výpis 7.11 Rozdílné generace viru W32/Evol. a. První generace: C7060F000055

mov

C746048BEC5151 mov

dword ptr [esi],5500000Fh dword ptr [esi+0004],5151EC8Bh

b. Druhá generace: BF0F000055

mov

edi,5500000Fh

893E

mov

[esi],edi

5F

pop

edi

52

push

edx

B640

mov

dh,40

BA8BEC5151

mov

edx,5151EC8Bh

53

push

ebx

8BDA

mov

ebx,edx

895E04

mov

[esi+0004],ebx

c. Další generace s přepočítanými konstantami: BB0F000055

mov

891E

mov

ebx,5500000Fh [esi],ebx

5B

pop

ebx

51

push

ecx

B9CB00C05F

mov

ecx,5FC000CBh

81C1C0EB91F1

add

ecx,F191EBC0h ; ecx=5151EC8Bh

894E04

mov

[esi+0004],ecx

V září roku 2000 se objevily varianty rodiny virů W95/Zperm, které používají metodu známou z DOSového viru Ply. Tento virus vkládá do svého kódu instrukce skoku, které vedou na nové instrukce viru.

Tělo viru je vystavěno v 64 kB velkém bufferu, který je zpočátku vyplněn nulami. Virus nepoužívá žádné dekódování a neregeneruje své konstantní tělo úplně všude. Místo toho vytváří mutace odstraňováním a přidáváním instrukcí skoku a smetí. Neexistuje žádný způsob, pomocí kterého by bylo možné tento virus detekovat – s využitím vyhledávacích řetězců – a to jak v souborech, tak i v paměti.

Většina polymorfních virů se dekóduje do konstantního těla v paměti, metamorfní viry to ovšem nedělají. Proto musí být detekce kódu viru v paměti vyřešena algoritmicky, protože tělo viru není konstantní ani zde. Obrázek 7.6 zobrazuje změny v struktuře kódu viru Zperm.

Počítačové viry – analýza útoku a obrana

Obrázek 7.6

249

Virus Zperm.

Někdy virus nahradí instrukce jinými, ekvivalentními instrukcemi. Například instrukce xor eax, eax, která vynuluje registr eax, se nahradí instrukcí sub eax, eax, která jej vynuluje také, přičemž operační kódy těchto instrukcí budou odlišné.

Samotné instrukce viru mají stejné pořadí vykonávání, skoky se nicméně vkládají na náhodná místa.

Varianta B viru také používá vkládání a odstraňování instrukcí smetí, jako je třeba nop (instrukce, která nic nedělá). Je zde jasně vidět, že počet různých generací může být minimálně n!, kde n je počet instrukcí v těle viru.

Zperm současně představil engine RPME (Real PerMutating Engine, opravdový permutační engine), který mohou využít jiní autoři k vytvoření nových metamorfních virů. Musím však podotknout, že permutace je pouze jednou z více používaných metamorfních technik. K vytvoření skutečně metamorfního viru se rovněž provádějí změny v operačních kódech a používá se šifrování v kombinaci s technikami polymorfismu a obrany proti emulaci.

V září roku 2000 dva autoři virů vytvořili nový permutační virus W95/Bistro, který byl založen na zdrojových kódech viru Zperm a jeho RPME. Aby se věc ještě více zkomplikovala, virus používal engine, který uměl náhodně vkládat bloky kódu. Náhodně aktivovaná rutina vybudovala nic nedělající blok kódu ve vstupním bodě viru před jeho vlastními instrukcemi. Jakmile se virus spustil, blok kódu vygeneroval milióny iterací pro vyřazení emulátoru ze hry.

Jednoduché permutační viry a komplexní metamorfní viry se mohou výrazně lišit ve složitosti své implementace. V každém případě jsou oba typy virů odlišné od těch tradičních polymorfních.

V případě polymorfních virů existuje určitý moment, ve kterém můžeme zachytit snímek kompletně dekódovaného těla viru, jak je vidět na obrázku 7.7. Antivirový software typicky používá generický dekódovací engine (založený na emulaci), aby tento proces vykonal. K přesné identifikaci viru antivirovým skenerem není nutné mít jeho kompletní snímek – je ale nezbytné najít ten správný moment během vykonávání kódu viru, kdy je možné snímek udělat, abychom mohli virus klasifikovat jako tradiční polymorfní. Je ovšem možné efektivně analyzovat i částečné výsledky, zejména tehdy, pokud je dekódovaná oblast dostatečně velká pro každou možnou generaci viru.

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

250

Obrázek 7.7

Snímek dekódovaného polymorfního viru.

A naopak – komplexní metamorfní viry neumožňují onen správný moment určit. To platí i pro viry, které používají metamorfní techniky společně s tradičními polymorfními technikami.

7.6.4 Mutování dalších aplikací: definitivní generátor virů?

W95/Bistro v nových generacích mutuje nejenom sám sebe, ale také kód svého hostitele – pomocí náhodně vykonávané rutiny pro morfování kódu. Tímto způsobem virus dokáže generovat nové červy a viry. Navíc virus nemůže být bezchybně odstraněn, protože oblast vstupního bodu aplikace se může lišit. Sekvence kódu u vstupního bodu hostitelské aplikace se mění v prvních 480 bajtech. Další výpis znázorňuje původní a permutovanou sekvenci kódu vstupního bodu: Původní kód ve vstupním bodě: 55

push

ebp

8BEC

mov

ebp, esp

8B7608 mov

esi, dword ptr [ebp + 08]

F6 85F6

test

esi, esi

743B

je

401045

8B7E0C mov

edi, dword ptr [ebp + 0c]

FF 09FF

or

edi, edi

7434

je

401045

31D2

xor

edx, edx

Permutovaný kód ve vstupním bodě: 55

push

ebp

54

push

esp

5D

pop

ebp

8B7608 mov

esi, dword ptr [ebp + 08]

F6 09F6

or

esi, esi

743B

je

401045

8B7E0C mov

edi, dword ptr [ebp + 0c]

FF 85FF

test

edi, edi

7434

je

401045

D2 28D2

sub

edx, edx

Počítačové viry – analýza útoku a obrana

251

Instrukce typu test esi, esi jsou tedy nahrazeny ekvivalentním or esi, esi. Sekvence push ebp; mov ebp, esp (která je velmi často používaná ve vysokoúrovňových jazycích) může být permutována na push ebp; push esp, pop ebp. Nahradit kód jiným kódem s odlišnou velikostí by sice bylo mnohem složitější, nicméně by pak bylo možné zkrátit některé delší instrukce a mezeru vyplnit nic nedělajícím kódem. V tomto případě se jedná o problém všech skenerů.

Pokud by virus nebo 32bitový červ implementoval podobnou morfovací techniku, byl by problém mnohem závažnější. Nové mutace starých virů a červů by se mohly objevovat donekonečna! Virtuálně nekonečný počet nových a doposud nedetekovaných virů a červů se mohou v budoucnu objevit bez jakéhokoliv lidského zásahu, což by vedlo k definitivnímu generátoru virů.

Poznámka Ještě sofistikovanější technika byla vyvinuta virem W95/Zmist22, který je popsán v následující části.

Koncem roku 1999 se objevil trojský kůň W32/Smorph, který při instalaci zadních vrátek (tzv. backdoor) do systému implementuje semi-metamorfní techniku. Samotný spustitelný soubor je kompletně regenerován během instalace trojského koně. Znovu se vytvoří PE hlavička a zahrnou se do ni nová jména sekcí a jejich velikosti. Kód ve vstupním bodě programu se vygeneruje metamorfně. Kód alokuje paměť a pak dekóduje svoje vlastní zdroje, které obsahují sadu dalších spustitelných souborů. Trojský kůň používá API volání do své tabulky adres importů, která je vyplněna mnoha nedůležitými API záznamy společně s těmi nezbytnými. V nových generacích tak bude celý kód trojského koně úplně jiný.

7.6.5 Pokročilé metamorfní viry: Zmist Během konference Virus Bulletin 2000 Dave Chess a Steve White z IBM demonstrovali výsledky svých výzkumů na téma nedetekovatelné viry. Krátce poté ruský autor virů Zombie vydal svůj magazín Total Zombification s řadou svých článků a virů. Jeden článek v tomto magazínu byl nazvaný jako "Undetectable Virus Technology" (Technologie nedetekovatelného viru).

Zombie už několikrát demonstroval svoje umění vytváření virů prostřednictvím svých všemožných polymorfních a metamorfních výtvorů. Jeho viry byly po léta distribuovány ve zdrojovém formátu a další autoři virů je modifikovali tak, aby vytvořili nové varianty. V případě viru W95/Zmist se jedná o jeho vskutku "mistrovské" dílo.

Mnoho z nás do té doby nespatřilo virus využívající tak komplexní techniku. Zmist můžeme bez obav zařadit na první místo ve složitosti binárních virů, které byly dosud napsány. W95/SK, One_Half, ACG a pár jiných virů se nabízí pro porovnání, ale Zmist nabízí trochu od všeho: používá techniku zatajení vstupního bodu (EPO) a je metamorfní. Virus navíc náhodně používá přídavný polymorfní decryptor.

Virus podporuje novou unikátní techniku – integraci kódu. Jeho engine Mistfall umí dekompilovat PE soubory na nejmenší prvky, na což vyžaduje 32 MB paměti. Zmist se vloží do kódu hostitele, přesune bloky kódu jinam, vloží sám sebe, zregeneruje kód a data (včetně relokačních informací) a znovu vytvoří spustitelný soubor. Jedná se o techniku, která nikdy před ním nebyla ve viru spatřena.

252

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

Zmist příležitostně vkládá instrukce skoku za každou instrukci v sekci kódu, které vedou na další instrukce. Je podivuhodné, že takto příšerně modifikované programy stále fungují jako dřív, z generace na generaci. V praxi jsme nezaznamenali jediný pád aplikace způsobený během replikace. Nikdo neočekával, že to může fungovat – dokonce ani samotný autor Zombie. Člověku navíc někdy zabere dost času, než přijde na to, že virus nějaké soubory infikoval. Vzhledem k této mimořádné kamufláži můžeme Zmist považovat za dokonalý antiheuristický virus. Říká se, že dobrý obrázek dokáže nahrat tisíc slov. Jako nejjednodušší analogie se nabízí model T-1000 z filmu Terminátor 2. Zmist se integruje do kódové sekce infikované aplikace podobně jako se T-1000 dovedl ukrýt na podlaze.

7.6.5.1 Inicializace Zmist nijak nemění vstupní bod hostitele, místo toho se smíchá s jeho existujícím kódem a stane se součástí jeho toku. Protože se kód umísťuje na náhodné místo, může se stát, že virus nikdy nezíská řízení.

Pokud se virus aktivuje, okamžitě spustí hostitele jako separátní proces a ukryje původní proces (pokud platforma podporuje funkci RegisterServiceProcess()) až do doby, než skončí jeho infekční rutina. Mezitím virus začne vyhledávat soubory vhodné k infikování.

7.6.5.2 Infekce přímé akce Po spuštění hostitelského procesu virus zkontroluje, zda-li je k dispozici alespoň 16 MB fyzické paměti.

Virus také zkontroluje, zdali neběží v "konzolovém režimu" (console mode). Pokud tyto testy projdou, virus alokuje několik paměťových bloků (včetně 32 MB oblasti pro pracovní prostor Mistfallu), permutuje tělo viru a začne rekurzivně vyhledávat PE soubory. Toto prohledávání se odehraje v adresáři Windows a všech podadresářích, v adresářích uvedených v proměnné prostředí PATH a rovněž na všech pevných nebo přenosných discích A: až Z:. Jedná se o šíření dosti hrubou silou.

7.6.5.3 Permutace Permutace je vcelku pomalá a proto se provádí pouze jednou, během infikování počítače. Sestává se z nahrazování instrukcí, jako je třeba převádění podmíněných skoků, převádění sekvencí push/pop na instrukce přesunu, alternativní zašifrování operačních kódů, záměna instrukcí XOR/SUB a OR/TEST a generování instrukcí pro smetí. Jedná se o stejný engine RPME, který už byl použit některými viry (včetně W95/Zperm, rovněž od Zombieho).

7.6.5.4 Infekce PE souborů Soubor se považuje za infikovatelný v případě, že splňuje následující podmínky: 

Je menší jak 448 kB.



Začíná značkou MZ (Windows nepodporují aplikace formátu ZM).



Není už infikovaný (infekční značka je Z na offsetu 0x1C v MZ hlavičce, tato položka se ve Windows aplikacích nepoužívá).



Je to PE soubor.

Počítačové viry – analýza útoku a obrana

253

Virus přečte celý soubor do paměti a pak vybere jeden ze tří možných typů infekce. S pravděpodobností jedna ku desíti se mezi každou instrukci vloží instrukce skoku (pokud se rovnou nejednalo o instrukci skoku). Soubor poté není infikován. Potom existuje další pravděpodobnost jedna ku desíti, že soubor bude infikován nezakódovanou kopií viru. Vlastní proces infekce je chráněn strukturovanou obsluhou výjimek, která zabraňuje pádům programu v případě, že dojde k chybě. Po přestavění spustitelného souboru se původní soubor smaže a vytvoří se místo něj ten infikovaný. Pokud ovšem během infekce došlo k chybě, je původní soubor ztracen a nezůstane po něm nic.

Polymorfní decryptor se skládá z "ostrůvků" kódu, které jsou integrovány do náhodných oblastí v sekci kódu hostitele a propojeny mezi sebou skoky. Integrace decryptoru se provádí stejně jako integrace těla viru – stávající instrukce jsou přesunuty na obě strany a mezi ně se vloží blok kódu. Polymorfní decryptor sice používá absolutní odkazy do datové sekce, ale engine Mistfall aktualizuje i relokační záznamy pro tyto odkazy. Při decryptování se používá následující antiheuristický trik – místo označení sekce kódu jako zapisovatelné se vybere pouze takový hostitel, který má alespoň jednu sekci zapisovatelnou s inicializovanými daty. Virtuální velikost sekce se zvětší o 32 kB, což je dostatečně velká oblast pro dekódované tělo a všechny proměnné, které se při dekódovaní používají. To viru umožňuje dekódovat svůj kód přímo do datové sekce a tam posléze předat řízení.

Pokud takovou sekci nenajde, virus infikuje soubor bez použití šifrování. Decryptor převezme řízení jedním ze čtyř následujících způsobů: 

Přes absolutní nepřímé volání (0xFF 0x15).



Přes relativní volání (0xE8).

Přes relativní skok (0xE9). 

Jako část vlastního toku programu.

Jestliže se použije jedna z prvních tří metod, virus převezme řízení těsně za vstupním bodem. V případě poslední metody se ostrůvky decryptoru vloží doprostřed některé subrutiny, někde v hostitelském kódu (včetně kódu před vstupním bodem). Všechny registry se před dekódováním uloží a na konci obnoví, takže původní kód funguje jako dřív. Zombie tuto metodu nazývá jako UEP, což je akronym k "Unknown EntryPoint" (neznámý vstupní bod), protože nikde neexistuje žádný přímý ukazatel na decryptor.

Pokud se použije šifrování, kód viru se zakóduje použitím instrukcí ADD, SUB nebo XOR s náhodným klíčem, který se mění každým průchodem další operace ADD/SUB/XOR s druhým náhodným klíčem, přičemž mezi instrukce dekódování se vloží různé instrukce smetí. Ty používají náhodný počet registrů a náhodné smyčky. O to všechno se stará engine ETG (Executable Trash Generator, generátor spustitelného smetí), který také vytvořil Zombie. Náhodnost je v tomto viru dost vyvinutá.

7.6.5.5 Integrace kódu Integrační algoritmus vyžaduje hostitele s relokačními záznamy, díky kterým se dají rozeznat offsety a konstanty. Po infekci nicméně nejsou tyto záznamy virem vyžadovány. Ačkoliv se pokouší v této oblasti najít zhruba 20 kB velkou mezeru (což by mohlo napovědět, kde je uloženo tělo viru), bylo by nebezpečné na toto spoléhat během skenování.

254

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

Pokud tyto záznamy už odstranila jiná aplikace (třeba nějaký jiný virus), infekce by zůstala skrytá. Algoritmus také vyžaduje, aby každá sekce hostitele měla jedno z následujících jmen: CODE, DATA, AUTO, BSS, TLS, .bss, .tls, .CRT, .INIT, .text, .data, .rsrc, .reloc, .idata, .rdata, .edata, .debug a DGROUP. Tyto sekce vytváří většina běžných kompilátorů a assemblerů od Microsoftu, Borlandu a Watcomu. Tyto řetězce nejsou ve viru vidět, protože jsou zakódované.

Dále se alokuje blok paměti, který je velký stejně jako hostitel v paměti a každá sekce se do tohoto bloku nahraje podle příslušné RVA (Relative Virtual Address, relativní virtuální adresa). Umístění každé důležité virtuální adresy se poznamená (importované a exportované funkce, zdroje, relokační záznamy a vstupní bod) a začne se s procházením instrukcí.

To je použito k přestavění (rebuild) spustitelného souboru. Jakmile se vloží instrukce do kódu, všechny následující odkazy na kód a data se musí přepočítat. Některé z těchto odkazů mohou být cílové adresy různých větví programu, a v některých případech se následkem změn tyto větve zvětší. Pokud k tomu dojde, musí se přepočítat další kód a data, které mohou být opět cílovými adresami větví programu a tento cyklus se opět opakuje. Naštěstí – z pohledu Zombieho – tato rekurze není nekonečná a ačkoliv se musí provést významný počet změn, tento počet změn je omezený. Procházení instrukcí se skládá z určení typu a délky každé instrukce. K popisu typů se používají různé příznaky, instrukce třeba obsahuje absolutní offset, který vyžaduje relokaci, instrukce pak obsahuje odkaz na kód atd.

V některých případech se instrukce nedá rozluštit tak, aby se jednoznačně určilo, že jde o kód nebo o data. V takovém případě Zmist soubor neinfikuje. Po fázi projití instrukcí se zavolá mutační engine, který za všechny přítomné instrukce vloží instrukce skoku nebo vygeneruje decryptor a vloží jeho "ostrůvky" do souboru. Soubor se přestaví, aktualizují se relokační záznamy, přepočítají se offsety, a také kontrolní součet souboru. Pokud byla za původním souborem uložená nějaká překrytá (overlay) data, virus je zkopíruje na konec nového souboru.

7.6.6 {W32,Linux}/Simile: metamorfní engine napříč systémy W32/Simile je posledním "produktem" vývoje metamorfního virového kódu. Virus byl publikován v šestém čísle magazínu 29A začátkem března roku 2002 a byl napsán autorem virů, který si říka The Mental Driller. Některé jeho předešlé viry, jako třeba W95/Drill (který používal polymorfní engine Tuareg), už byly velmi obtížně detekovatelné.

W32/Simile implementuje další krok ve složitosti. Zdrojový kód viru má přibližně 14000 řádek assemblerového kódu. Zhruba 90 % virového kódu zabírá samotný metamorfní engine, který je ovšem velmi výkonný. Autor viru jej nazval MetaPHOR, což je zkratka pro "METAmorphic Permutating High-Obfuscating Reassembler".

První generace kódu viru má zhruba 32 kB a v oběhu jsou tři známé varianty viru. W32/Simile je velmi matoucí virem a současně velkou výzvou pro antivirový výzkum. Virus útočí na techniky disassemblování, ladění a emulace, stejně jako na standardní techniky analýzy založené na vyhodnocování a vypočítávání. A stejně jako mnoho jiných komplexních virů i virus Simile používá EPO techniky.

Počítačové viry – analýza útoku a obrana

255

7.6.6.1 Replikační rutina Simile obsahuje dobře známý replikační mechanismus přímé akce, který infikuje PE soubory na lokálním stroji a síti. Důraz je kladen na metamorfní engine, který je neobvykle složitý.

7.6.6.2 EPO mechanismus Virus vyhledává a nahrazuje všechny možné vzorky instrukcí volání (ty, které se odkazují na API volání ExitProcess()) takovým způsobem, aby ukazovaly na začátek virového kódu. Vstupní bod programu tedy zůstává netknutý. Metamorfní tělo viru je někdy umístěno dohromady s polymorfním decryptorem na stejné místo v souboru, v jiných případech je polymorfní decryptor umístěn na konec kódové sekce, přičemž tělo viru není uloženo zde, ale v jiné sekci. Tím je utajeno pravé umístění těla viru.

7.6.6.3 Polymorfní decryptor Během spouštění infikovaného programu, jakmile tok programu dosáhne na jeden ze závěsů (hooks), které virus umístil do kódové sekce, převezme řízení polymorfní decryptor zodpovědný za dekódování těla viru (nebo za přímé kopírování, což značí že tělo viru nemusí být vždy zakódované).

Tento decryptor, jehož umístění v souboru je proměnné, prvně alokuje velkou oblast v paměti (okolo 3.5 MB) a následně tam dešifruje zakódované tělo. Nedělá to ovšem obvyklým způsobem – místo toho, aby lineárně dekódoval zakódovaná data, tak je zpracovává v rádoby-náhodném pořadí, čímž zmátne některé heuristiky zaměřené na rozpoznání decryptovací smyčky. Toto "pseudo-náhodné indexové dekódování" (autor viru jej nazývá jako PRIDE – "Pseudo-Random Index DEcryption") spočívá v použití rodiny funkcí, které mají zajímavé algoritmické vlastnosti, modulo 2^n. Ačkoliv na to autor viru přišel metodou pokus-omyl, je skutečně možné poskytnout matematický důkaz toho, že jeho algoritmus bude pracovat ve všech případech (samozřejmě za předpokladu, že je příslušná implementace algoritmu správná). S tímto důkazem přišel Frederic Perriot z firmy Symantec.

Velikost a vzhled decryptoru se významně liší z jedné generace na druhou. K dosažení této výjimečné variability autor viru jednoduše generuje šablonu kódu a potom pro ni volá metamorfní engine, který šablonu převede na funkční decryptor.

V některých případech může decryptor začít hlavičkou, jejíž záměr není v daném okamžiku zřejmý. Následný výzkum prozrazuje, že jejím smyslem je generování kódu za běhu s obranou proti emulaci. Virus vytvoří malý kousek oligomorfního kódu obsahující instrukci RDTSC (ReaD Time Stamp Counter, přečti časové razítko), která se postará o získání hodnoty z interního čítače procesoru. A potom, v závislosti na náhodném bitu této hodnoty, decryptor buď dekóduje a spustí tělo viru nebo obejde proces dekódování a jednoduše se ukončí.

Kromě matení emulátorů, které nepodporují instrukci RDTSC, se také jedná o velmi silný útok proti všem algoritmům založeným na emulaci, které se starají o dekódování těla viru nebo zjištění podezřelého chování – protože se efektivně zajišťuje náhodná nefunkčnost některých virových vzorků.

Jakmile se spustí tělo viru, získá adresy dvaceti API funkcí, které potřebuje pro svoji replikaci a zobrazení payloadu. Potom virus zjistí aktuální systémové datum a v závislosti na něm se aktivuje payload ruti-

256

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

ny. Obojí vyžaduje, aby hostitel importoval nějaké funkce z knihovny USER32.DLL. V kladném případě virus ověří, zdali může volat svoji payload rutinu (ta je více rozebraná dále).

7.6.6.4 Metamorfismus Poté přijde na řadu generování těla viru. Tento proces generování kódu se odehrává v těchto krocích: 1. Tělo viru se disassembluje do jakéhosi mezijazyka, který je nezávislý na konkrétním CPU, který vykonává nativní instrukce. To umožňuje budoucí rozšíření, jako třeba vytvoření kódu pro různé operační systémy běžících na různých procesorech.

2. Kód v mezijazyce se zmenší odstraněním redundantních a nepoužitých instrukcí. Tyto instrukce sem byly přidány během předchozích replikací, aby byl ztížen proces disassemblování antivirovými výzkumníky.

3. Kód v mezijazyce se dále permutuje, například přeuspořádáním subrutiny nebo separováním bloků kódu a jejich spojení pomocí instrukcí skoku.

4. Kód se zvětší přidáním redundantních a nepoužitých instrukcí.

5. Kód se reassembluje do finální podoby a přidá se do infikovaných souborů.

Virus Simile se dokáže nejenom zvětšovat jako většina metamorfních virů první generace, ale umí se také zmenšovat, a to do různých forem. Simile.D se umí přeložit do různých metamorfních forem (V1, V2C9Vn) a dovede to dělat na více, než na jednom operačním systému (O1,O2C9On). Virus se zatím nedokáže vygenerovat pro více druhů procesorů, nicméně techniky přeložení kódu a metamorfismu pro odlišné procesory (P1…Pn) jsou v budoucnu možné, jak je vidět na obrázku 7.8.

Obrázek 7.8

Virus Simile šířený z Linuxu na Windows z jedné generace na druhou.

7.6.6.5 Replikace Fáze replikace přichází na řadu teď. Začne se vyhledáváním *.exe souborů v aktuálním adresáři a potom na všech pevných a síťových discích. Prohledávání adresářů je sice rekurzivní, ale pouze do hloubky tří podadresářů. Neinfikují se adresáře, které začínají na písmeno W. Pro každý nalezený soubor existuje 50% pravděpodobnost, že soubor bude přeskočen. Soubory se přeskočí, pokud začínají písmeny F-, PA, SC, DR, NO nebo tehdy, pokud obsahují písmeno V (kdekoliv ve jméně). Kvůli povaze porovnávání jsou neúmyslně přeskočeny ostatní kombinace znaků, jako třeba adresáře, které začínají číslem 7, libovolné soubory začínající na FM nebo obsahující kdekoliv ve jméně číslo 6.

Počítačové viry – analýza útoku a obrana

257

Infekční rutina obsahuje mnoho kontrol, aby odfiltrovala soubory, které nedovede bezpečně infikovat.

Tyto testy zahrnují podmínky typu, že daný soubor musí obsahovat kontrolní součet, musí to být soubor spustitelný na platformě Intel 386+ či musí obsahovat sekci, jejíž jméno je .text nebo CODE a .data nebo DATA. Virus také zkontroluje, zda-li hostitelský program importuje některé funkce jádra, jako třeba ExitProcess.

Pro každý soubor, který se považuje za infikovatelný, existují různé náhodné faktory (např. struktura kódu), které rozhodnou, kde bude umístěn decryptor a tělo viru. Pokud soubor neobsahuje žádné relokace, virus se připojí na konec poslední sekce v souboru (k tomu může nicméně dojít i náhodou, bez ohledu na přítomnost relokačních záznamů).

V tomto případě bude decryptor umístěný před tělem viru nebo na konci kódové sekce. Pokud je jméno poslední sekce .reloc, virus se vloží na začátek datové sekce, posune všechna následující data a aktualizuje všechny offsety v souboru.

7.6.6.6 Payload První payload se aktivuje pouze během března, června, září nebo prosince. Varianty A a B viru W32/ Simile zobrazí svou hlášku 17. dne v těchto měsících, varianta C zobrazí svou hlášku 18. dne. Varianta A zobrazí zprávu "Metaphor v1 by The Mental Driller/29A", varianta B zobrazí text "Metaphor 1b by The Mental Driller/29A" a varianta C "Deutsche Telekom by Energy 2002 **g**". Autor varianty C měl nicméně malé programátorské schopnosti a tak se zpráva málokdy zobrazí tak, jak by měla. Ve všech případech jsou velikosti písmen zobrazeny náhodně, jak je vidět na obrázku 7.9.

Druhý payload se ve variantách A a B aktivuje 14. května a 14. června ve variantě C. Varianty A a B na počítačích s hebrejskou lokalizaci zobrazí řetězec "Free Palestine!". Varianta C obsahuje text "Heavy Good Code!", ale díky chybě se zobrazí pouze na systémech, jejichž lokalizace nejde rozpoznat.

a) Varianta A.

c) "Neoficiální" varianta C.

b) Varianta B.

d) Varianta D (která byla autorovou "oficiální" variantou C).

Obrázek 7.9

"Metamorfní" aktivační rutiny viru Simile.

První W32/Linux infektor pojmenovaný jako {W32,Linux}/Peelf, používá pro infekci PE a ELF souborů dvě separátní rutiny. Simile.D sdílí značné množství kódu mezi dvěmi infekčními rutinami, jako třeba

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

258

polymorfní a metamorfní enginy. Jedinou částí infekční rutiny, která je závislá na konkrétní platformě, je pohyb napříč adresářemi a používání API. Bylo potvrzeno, že virus se dovede úspěšně replikovat na systémech Red Hat Linux 6.2, 7.0 a 7.2 a s největší pravděpodobností funguje na většině linuxových distribucích.

Infikované soubory se zvětší průměrně o 110 kB, velikost viru je nicméně variabilní vzhledem k metodě infekce a ke schopnosti metamorfního enginu zmenšovat a zvětšovat kód viru.

Jakmile se varianta D aktivuje na systému Linux, na konzoli se zobrazí zpráva (viz obrázek 7.10).

Obrázek 7.10

Payload viru Simile.D na systému Linux.

7.6.7 Temná budoucnost – metamorfní MSIL viry Jak už bylo řečeno v této kapitole, v dnešní době existují nové MSIL viry, jako třeba MSIL/Gastropod, které podporují semi-metamorfní (permutační) generování kódu pod .NET Framework. Takové viry mají obrovskou výhodu, protože nemusí nést svůj vlastní zdrojový kód – mohou se totiž snadno dekompilovat a generovat nové binární soubory, třeba s použitím jmenného prostoru System.Reflection.Emit.

Následující výpis 7.12 znázorňuje metamorfní MSIL engine dvou generací viru MSIL/Gastropod.

Výpis 7.12 Různé generace viru MSIL/Gastropod. a.) .method private static hidebysig specialname void .cctor() { ldstr "[ .NET.Snail - sample CLR virus (c) whale 2004 ]" stsfld class System.String Ylojnc.lgxmAxA::WaclNvK nop ldc.i4.6 ldc.i4.s 0xF call int32 [mscorlib]System.Environment::get_TickCount() nop newobj void nljvKpqb::.ctor(int32 len1,int32 len2, int32 seed) stsfld class nljvKpqb Ylojnc.lgxmAxA::XxnArefPizsour call int32 [mscorlib]System.Environment::get_TickCount()

Počítačové viry – analýza útoku a obrana

259

nop newobj void [mscorlib]System.Random::.ctor(int32) stsfld class [mscorlib]System.Random Ylojnc.lgxmAxA::aajqebjtoBxjf ret } b.) .method private static hidebysig specialname void .cctor() { ldstr "[ .NET.Snail - sample CLR virus (c) whale 2004 ]" stsfld class System.String kivAklozuas.ghqrRrlv::ngnMTzqo ldc.i4.6 ldc.i4.s 0xF call int32 [mscorlib]System.Environment::get_TickCount() xiWtNaocl::.ctor(int32 len1, int32 len2, int32 seed) newobj void xiWtNaocl stsfld class xiWtNaocl kivAklozuas.ghqrRrlv::yXuzlmssjjp call int32 [mscorlib]System.Environment::get_TickCount() newobj void [mscorlib]System.Random::.ctor(int32) stsfld // line continues on next line class [mscorlib]System.Random kivAklozuas.ghqrRrlv::kaokaufdiehjs nop ret }

Zobrazené části kódu reprezentují konstruktor třídy (".cctor") dvou generací viru MSIL/Gastropod. Semi-metamorfní engine viru zamaskuje jména tříd a metod23. Navíc permutační engine viru ze svého těla vkládá a odstraňuje instrukce smetí (jako je třeba nop). Vývojářům MSIL není příliš známo, že mohou volat kompilátor a generovat kód a sestavy (assembly) z běžící aplikace, ovšem autoři virů tuto vlastnost dobře znají a také využívají.

MSIL/Gastropod je virus, který si vybuduje vlastní kód tak, že smíchá hostitele se svým vlastním kódem.

Tato metoda umožňuje, aby bylo tělo viru uloženo na nepředvídatelném místě v hostitelském programu. Hlavní vstupní bod hostitele je nahrazen vstupním bodem viru. Jakmile dojde ke spuštění hostitele, zavolá se kód viru, který následně zavolá původní vstupní bod hostitele.

Některé viry se z důvodu implementace parazitické MSIL infekce nespoléhají na používání jmenných prostorů .NET Frameworku. Například virus MSIL/Impanate napsaný Roy g Bivem dovede správně pracovat jak v 32bitových, tak i v 64bitových MSIL souborech a infikovat je pomocí EPO techniky. Nové generace metamorfních MSIL virů se patrně nebudou vůbec spoléhat na jmenný prostor System.Reflection.Emit, a ani na jakýkoliv jiný podobný.

260

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

7.7 Generátory počítačových virů Autoři virů se soustavně snaží zjednodušovat proces vytváření virových kódů. Většina virů byla ovšem napsána v jazyce assembler, který je pro většinu dětí příliš obtížný. To inspirovalo autory k vytvoření různých generátorů, které dovedou používat takřka všichni, co umí pracovat s počítačem.

Generátory virů se vyvíjely po několik let, podobně jako se vyvíjely viry pro nové platformy. Pro generování široké palety nebezpečných kódů (jako jsou třeba DOSové COM a EXE viry, 16bitové viry pro Windows, dávkové a skriptovací viry, makroviry pro Word, PowerPoint a Excel, červi pro mIRC atd.) byly vyvinuty různé generátory a mutační enginy. Pomocí těchto generátorů je v dnešní době možné generovat i PE viry.

Generátory virů se těší velkému zájmu antivirových firem. Je totiž nemožné předvídat, zdali autoři virů vytvoří nebo nevytvoří nový virus prostřednictvím nějakého generátoru, a proto musí antiviroví výzkumníci strávit mnoho času i s těmi nejprimitivnějšími nástroji jenom proto, aby zjistili, jaké viry umí generátor vytvářet a následně vypracovali návrhy detekce a léčení pro všechny možné případy. A aby toho nebylo málo, spousta generátorů vytváří zdrojové kódy namísto binárních, takže začínající útočník může kód dále pozměnit a přidat více funkcí, takže nikdy není možné dosáhnout perfektní ochrany.

A aby měly antivirové skenery práci ještě těžší, generátory virů přicházejí s takovými technikami ochrany, jako je třeba šifrování nebo s obranou proti ladění, emulaci a monitorům podezřelého chování. Některé generátory umí dokonce měnit kód podobným způsobem, jako to dělají metamorfní enginy.

7.7.1 VCS ( Virus Construction Set) Prvním generátorem virů byl program VCS napsaný v roce 1990 a jeho autoři byli členy Verband Deutscher Virenliebhaber (Asociace německých milovníků virů).

VCS byl vcelku jednoduchým nástrojem. Všechny viry, které uměl generovat, byly velké 1077 bajtů a ukládaly se jako soubor na disku pod jménem VIRUS.COM. Uživatel mohl pouze specifikovat jméno textového souboru se zprávou a číslo generace pro zobrazení tohoto textu. VCS viry dovedly infikovat pouze DOSové COM soubory, payload viru spočíval v mazání souborů AUTOEXEC.BAT a CONFIG. SYS a v zobrazení definovaného textu.

Viry pocházející z generátoru VCS byly jednoduché a nezakódované. Jedinou speciální funkcí VCS virů bylo to, že dovedly zjistit přítomnost monitoru podezřelého chování FluShot, přičemž se v takovém případě přestaly dále šířit.

7.7.2 GenVir V letech 1990-1991 byl ve Francii vypuštěn jako shareware generátor GenVir, který napsal J. Struss.

Původním záměrem bylo "testování" schopností antivirových produktů nějakým nástrojem, který by dokázal vytvářet nové replikující se viry. Tímto nástrojem bylo vytvořeno pouze několik virů. V roce 1993 byla vypuštěna nová verze generátoru, která už podporovala nové verze DOSu.

Počítačové viry – analýza útoku a obrana

261

7.7.3 VCL ( Virus Creation Laboratory) V roce 1992 byl v USA vytvořen generátor VCL (zobrazen na obrázku 7.11). Jeho autor byl členem virové skupiny NuKE a říkal si Nowhere Man. Generátor VCL vypadal mnohem lépe než jeho předchůdci, protože měl IDE založené na C++ 3.0 od Borlandu a podporoval myš. Namísto vytváření binárních souborů VCL dovedl generovat zdrojové kódy v jazyce assembleru. Tyto zdrojové kódy bylo zapotřebí zkompilovat a provázat, aby z nich útočník mohl vytvořit funkční viry. VCL podporoval velkou řadu payloadů, stejně jako technik zakódování a strategií infekce. Není překvapivé, že ne všechny vygenerované viry byly funkční, nicméně se lišily díky různým nastavením generátoru a jejich detekce nebyla tak jednoduchá jako v případě virů vytvořených VCS. Několik VCL virů se dokonce rozšířilo ve větším množství a bylo to poprvé, co i začínající útočník dokázal prostřednictvím viru způsobit velké škody.

Obrázek 7.11

GUI generátoru Virus Creation Laboratory.

7.7.4 PS-MPC (Phalcon-Skism Mass-Produced Code Generator) Protože jednotlivé virové skupiny mezi sebou navzájem soutěží, nemuseli jsme dlouho čekat na vznik dalšího programu pro generování virů. PS-MPC byl vytvořen v roce 1992 ve Spojených Státech autorem, který si říkal Dark Angel.

PS-MPC nemá přívětivé uživatelské rozhraní jako VCL, což jej činí nebezpečnějším nástrojem. Protože je PS-MPC dodáván ve formě skriptů, může být mnohem jednodušší vygenerovat stovky opsaných virů.

PS-MPC také generuje viry ve zdrojových kódech, podobně jako VCL, nicméně PS-MPC viry fungují lépe než ty z VCL. Není proto překvapením, že se autorům podařilo vygenerovat více než 15000 variant a uložit je na některé FTP servery antivirových společností.

Ačkoliv prvotní verze PS-MPC dokázaly vytvářet pouze viry přímé akce, jiné vypuštěné verze už dovedly vytvářet i paměťově rezidentní viry. Pozdější verze podporovaly také infekci EXE souborů.

262

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

PS-MPC byl jedním z důvodů, proč jsem se rozhodl napsat tuto kapitolu. Tvůrce PS-MPC totiž přišel na to, že aby generátory byly úspěšné, musí umět generovat odlišně vypadající viry. Aby toho generátor PS-MPC dosáhl, negeneruje polymorfní viry, ale mění jejich dekódovací rutiny a struktury.

Po PS-MPC velmi rychle následoval generátor druhé generace pojmenovaný jako G2. Ten k PS-MPC přidává techniky obrany proti ladění a emulaci s ještě větší obměnou decryptorů.

7.7.5 NGVCK (Next Generation Virus Creation Kit) NGVCK byl představen v roce 2001 autorem, který si říká SnakeByte. NGVCK (viz obrázek 7.12) je Win32 aplikace napsaná ve Visual Basicu. Tento nástroj je v mnoha směrech velmi podobný VCL, avšak na rozdíl od něj umí generovat 32bitové viry, které dovedou infikovat PE soubory. Existuje něco přes 30 verzí samotného NGVCK.

Obrázek 7.12

Hlavní menu generátoru NGVCK.

NGVCK má vylepšený engine pro morfování zdrojového kódu assembleru. Viry, které NGVCK vytváří, mají náhodné pořadí funkcí, vložené instrukce smetí a uživatelem definované metody šifrování. Virus také dokáže zaútočit na debugger SoftICE běžícím na systémech Windows 95. Pozdější verze generátoru také podporují infikování souborů prostřednictvím odlišných technik.

Viry vytvořené programem NGVCK jsou automaticky mofrovány, takže vždy, když někdo použije tento nástroj, vytvoří se nová varianta viru. Generování kódu používá principy popsané v kapitole 6 popisující základní obranné strategie virů. Bohužel je mnohem snazší vyvinout morfování zdrojových kódů namísto binárních, takže se dá předpokládat, že útočníci začnou v budoucnu používat i tyto techniky.

7.7.6 Další nástroje a mutační enginy Pro amatérské autory virů existuje něco přes 150 nástrojů a mutačních enginů, které mohou použít, přičemž mnoho z nich už bylo použito k vytvoření fungujících virů. V roce 1996 začaly být tyto nástroje velmi populární. Dostaly se k nám například nové viry z anglických škol, které byly vytvořeny generátorem IVP (Instant Virus Production kit). IVP naprogramoval v Turbo Pascalu tvůrce Admiral Bailey ze

Počítačové viry – analýza útoku a obrana

263

skupiny YAM (Youngsters Against McAfee). IVT podporuje infekci EXE a COM souborů, stejně jako šifrování a mutaci kódu – a děti jej měly velmi rády, protože obsahoval i aktivační rutiny (tzv. payload) ve formě trojských koňů.

Jedním z nejznámějších příkladů viru vytvořeného generátorem je obecně známý virus "Anna Kournikova". Tento červ byl vytvořen nástrojem VBSWG a jeho uživatel, dvacetiletý Holanďan, evidentně neuměl programovat, nicméně schopnost masivního šíření tohoto červa, zkombinovaná se sociálním inženýrstvím, zafungovala velmi efektivně. Mnoho uživatelů chtělo vidět fotku Anny Kournikové, ovšem namísto toho spustili červí skript. Tabulka 7.1 zobrazuje některé běžné generátory.

Tabulka 7.1 – Příklady generátorů počítačových virů.

Jméno generátoru

Popis

NRLG (NuKE’s Randomic Life Generator)

Vypuštěný v roce 1994 autorem Azrael. Velmi podobný VCL.

OMVCK (Odysseus Macro Virus Construction Kit)

Tento nástroj byl vypuštěn v roce 1998 a dovede generovat zdrojové kódy makrovirů ve Word Basicu.

SSIWG (Senna Spy Internet Worm Generator)

Vypuštěný v roce 2000 v Brazílii. Tento generátor umí vytvářet VBS červy.

NEG (NoMercy Excel Generator)

Jednalo se o první generátor makrovirů pro Excel (1998). Jako výstup generoval soubory .bas.

VBSWG (VBS Worm Generator)

Vypuštěný v roce 2000 autorem [K]Alamar, umí generovat různé skriptovací červy.

AMG (Access Macro Generator)

Vytvořený v roce 1998 autorem Ultras, generuje makroviry pro Access97.

DREG (Digital Hackers’ Alliance Randomized Encryption Generator

Vypuštěný v roce 1997 autorem Gothmog. Podporuje vylepšené morfování kódu a obranu proti heuristice.

V budoucnu můžeme očekávat snahu generátorů virů pokračovat ve vývoji směrem k síťovým virům a červům. Existuje už pár nástrojů, které se dají ovládat prostřednictvím CGI skriptu přes webové rozhraní. To útočníka zbavuje nutnosti zveřejňovat zdrojový kód virového generátoru, čímž dává antivirovým výzkumníkům méně šancí pro otestování schopností takových nástrojů.

7.7.7 Jak testovat generátory počítačových virů?

Použití generátorů virů není jen čistě technická otázka, je to také otázka etická. Jak pravil Alan Solomon, pro antivirového výzkumníka je etické generování a uchování virů na infikovaném počítači za předpokladu, že se vzorky odstraní ihned poté, jakmile je pro ně vyvinut detekční algoritmus. Vygenerované viry by neměly být nikde uloženy, ani pro pozdější testování. Jedná se o etický přístup všeobecně akceptovaný mezi antivirovými výzkumníky.

264

Kapitola 7 – Pokročilé techniky vývoje kódu a generátory počítačových ...

Odkazy 1. Fridrik Skulason, "Latest Trends in Polymorphism – The Evolution of Polymorphic Computer Viruses", Virus Bulletin Conference, 1995, str. I-VII. 2. Peter Szor a Peter Ferrie, "Hunting for Metamorphic", Virus Bulletin Conference, září 2001, str.

123-144.

3. Tim Waits, "Virus Construction Kits", Virus Bulletin Conference, 1993, str. 111-118.

4. Fridrik Skulason, "Virus Encryption Techniques", Virus Bulletin, listopad 1990, str. 13-16.

5. Peter Szor, "F-HARE", Documentation by Sarah Gordon, 1996.

6. Eugene Kaspersky, "Picturing Harrier", Virus Bulletin, září 1999, str. 8-9.

7. Peter Szor, Peter Ferrie a Frederic Perriot, "Striking Similarities", Virus Bulletin, květen 2002, str.

4-6.

8. X. Lai, J. L. Massey, "A Proposal for New Block Encryption Standard", Advances in Cryptology Eurocrypt’90, 1991.

9. Peter Szor, "Bad IDEA", Virus Bulletin, duben 1998, str. 18-19.

10. Peter Szor, "Tricky Relocations", Virus Bulletin, duben 2001, strana 8.

11. Dmitry Gryaznov, "Analyzing the Cheeba Virus", EICAR Conference, 1992, str. 124-136.

12. Dr. Vesselin Bontchev, "Cryptographic and Cryptanalytic Methods Used in Computer Viruses and Anti-Virus Software", RSA Conference, 2004.

13. James Riordan and Bruce Schneider, "Environmental Key Generation Towards Clueless Agents", Mobile Agents and Security, Springer-Verlag, 1998, str. 15-24.

14. Makoto Matsumoto a Takuji Nishimura, "Mersenne Twister: A 623-Dimensionally Equidistributed Uniform Pseudorandom Number Generator", ACM Transactions on Modeling and Computer Simulations: Special Issue on Uniform Random Number Generator, 1998, http://www.math. keio.ac.jp/~nisimura/random/doc/mt.pdf.

15. Peter Szor, "The Road to MtE: Polymorphic Viruses", Chip, červen 1993, str. 57-59.

16. Fridrik Skulason, "1260 – The Variable Virus", Virus Bulletin, březen 1990, strana 12.

17. Vesselin Bontchev, "MtE Detection Test", Virus News International, leden 1993, str. 26-34.

18. Peter Szor, "The Marburg Situation", Virus Bulletin, listopad 1998, str. 8-10.

19. Dr. Igor Muttik, "Silicon Implants", Virus Bulletin, květen 1997, str. 8-10.

20. Vesselin Bontchev a Katrin Tocheva, "Macro and Script Virus Polymorphism", Virus Bulletin Conference, 2002, str. 406-438.

21. "Shape Shifters", Scientific American, květen 2001, str. 20-21.

22. Peter Szor a Peter Ferrie, "Zmist Opportunities", Virus Bulletin, březen 2001, str. 6-7.

23. Peter Ferrie, osobní komunikace, 2004.

KAPITOLA 8 Klasifikace podle payloadu

"Myslím si, že i počítačové viry by se měly počítat k živým organismům. Možná to vypovídá něco o lidské přirozenosti, že jediná forma života, kterou jsme dokázali vytvořit, je čistě destruktivní povahy."

– Stephen Hawking

266

Kapitola 8 – Klasifikace podle payloadu

V této kapitole se dozvíte o běžných metodách aktivace počítačových virů. Existuje nespočet událostí, které mohou mít za následek aktivaci viru. Následuje seznam nejběžnějších metod, který nicméně ani zdaleka není úplný: 

Systémové datum nebo čas.



Časové/datové razítko konkrétního souboru.



Konkrétní jméno souboru.



Standardní nastavení systémového jazyka.



Jméno navštívené webové stránky.



IP adresa systému.



Použitý operační systém.



Částečná zranitelnost, která existuje pouze v určité verzi operačního systému, jako například v ruské verzi Windows.

V dnešní době jsou již uskutečnitelné i cílené virové útoky, přestože celková kontrola nad replikací kódu viru zůstává složitá, ale nikoliv neuskutečnitelná.

8.1 Bez payloadu Ve světě laiků bývá často cokoliv neobvyklého, co se přihodí při práci s počítačem, přisuzováno neznámému a "záhadnému viru". Ve skutečnosti je ovšem většina problémů spojených s počítači zapříčiněna čímkoliv jiným, jenom ne počítačovými viry. Výsledkem tohoto jevu je, že pracovníci IT oddělení mají tendenci být stále méně obezřetní a v případě exploze skutečné infekce jsou často velmi skeptičtí (zejména na samém začátku) a plýtvají tak časem. Jistě znáte obdobnou situaci z pohádek, kde hrdina zneužívá volání o pomoc, až v případě skutečného nebezpečí žádná pomoc nepřijde.

Dalším z řady problémů je, že lidé obecně předpokládají, že aby mohlo být něco označeno jako počítačový virus, musí to být spojeno s ničením uživatelských dat, například formátováním harddisku. Málokdo chápe, proč by někdo chtěl psát program, který se "pouze replikuje a šíří". Je ovšem skutečností, že většina počítačových virů se pouze replikuje a šíří. Mnohé z řady proof-of-concept virů náleží do této skupiny, jako například virus WM/Concept. Podobné viry mohou také obsahovat zprávu, která se nikdy nezobrazuje a obvykle je určena pro ty, u nichž se očekává, že by ji mohli nalézt – což můžou být například (anti)viroví výzkumníci. Nejnudnější viry neobsahují žádný text, pouze kód pro replikaci. Šíření virů má bohužel i stinné stránky. Těmi jsou například možnost náhodné ztráty dat díky pádu systému způsobené chybou v kódu viru, nebo náhodné přepsání časti disku obsahujícího důležitá data.

Viroví výzkumníci tento typ virů pojmenovali jako viry bez payloadu. Ovšem neexistuje nic takového, jako neškodný virus. Už samotnou replikací mohou být viry pro uživatele počítače nesmírně obtěžující.

Nikdy jsem nepotkal více než několik málo uživatelů, kteří mi řekli toto: "Ne, nemám s těmito třemi viry žádný problém. Jen infikují soubory. Klidně s nimi můžu na svém systému žít". Podobný způsob uvažování je velmi neobvyklý. Většina lidí je přítomností viru velmi znepokojena, ať už ze strachu ze ztráty dat, nebo z jiných důvodů. Odstranění virů může být velmi nákladná záležitost. Příkladem může být

Počítačové viry – analýza útoku a obrana

267

velká firma zabývající se výrobou hardware či software, která je napadena virem. Produkce nových systémů musí být zastavena, což může způsobit škody v řádu miliónů dolarů za každý neproduktivní den.

8.2 Náhodně destruktivní payload Některé viry (jako například Stoned) mohou ztrátu dat způsobit následkem své replikace. Poté, co virus uloží původní boot sektor, může přepsat důležitá data. Například tehdy, pokud je na disketě větší počet adresářů, virus Stoned některé z nich přepíše, protože původní boot sektor ukládá na konci kořenového adresáře. Výsledkem této činnosti je výpis nesmyslných znaků, místo názvu souborů a adresářů, pokud je na disketě spuštěn příkaz DIR. Soubory a adresáře mohou být v tomto případě ještě zachráněny pomocí nějakého disk-editoru, ale většina uživatelů tuto situaci zařadí do kategorie trvalé ztráty dat.

8.3 Nedestruktivní payload Přinejmenším polovina všech počítačových virů spadá do této kategorie. Některé viry při své aktivaci jednoduše na obrazovce zobrazí nějakou zprávu. V minulých kapitolách bylo uvedeno několik příkladů.

Autoři virů a škodlivého software jsou často motivováni politicky. Červ WANK1 je typickou ukázkou.

Byl uveřejněn na síti SPAN 16. října 1989. Přepisuje systémový titulek zprávou uvedenou na obrázku 8.1 pokaždé, když se uživatel přihlásí na DEC systému.

Obrázek 8.1

Zpráva uváděná červem WANK.

Některé počítačové viry, jako například W95/Marburg, mají payload vyvedený v grafice. Poté, co se Marburg aktivuje, nahraje si standardní zdroj ikon, IDI_HAND (0x7F01), který je používán v případě vážných systémových chyb a vloží jej na desktop. A nakonec zobrazí až 256 ikon na náhodná místa na ploše (viz obrázek 8.2).

Systém Windows 95 při pohybu okny překresluje velmi pomalu plochu, což časem vede k tomu, že ikony Marburgu zmizí, ale virus v kreslení ikon pokračuje stále dokola.

268

Obrázek 8.2

Kapitola 8 – Klasifikace podle payloadu

Aktivační rutina viru W95/Marburg.

Marburg je ovšem mnohem méně obtěžující, než například staré DOSové viry jako například Cascade, který způsoboval to, že jednotlivé znaky padaly na spodek obrazovky v kaskádovitých vlnách, doprovázené šumem z reproduktoru počítače (speakeru).

Jiné viry mají zabudované animace, které jsou přehrány po spuštění. Maďarský DOSový virus, G9Amb (HH&H), zobrazuje skákající 3D míček.

Pravděpodobně jedním z nejznámějších programátorů z této kategorie je francouzský autor Spanska, jež má na svém kontě například virus IDEA, který zobrazuje hned několik animací, mimo jiné tu, která je zobrazena na obrázku 8.3. Všechny viry od autora jménem Spanska patří do kategorie nedestruktivního payloadu.

Obrázek 8.3

Aktivační rutina Spanskeho IDEA viru.

Počítačové viry – analýza útoku a obrana

269

Nejznámější animace od tohoto autora bývá zobrazována virem W32/SKA (známého také jako červ Happy99, který je uváděn v kapitole 3 a 9). Některé viry jsou dokonce interaktivní a s uživatelem hrají hry. Příkladem může být například virus Playgame2.

Samozřejmostí je, že viry nejsou omezeny pouze na zobrazování animací a zpráv na obrazovce. Mohou používat reproduktory a přehrávat hudbu nebo se dokonce pokoušet o mluvené slovo. Na moderních počítačích není problém přehrávat soubory MP3 nebo WAV a viry toho dokáží využít. Některé obtěžující viry (a někdy i trojské koně se zadními vrátky do systému) opakovaně otevírají a zavírají dvířka CD-ROM mechaniky, což může uživatele vést k obavám, zdali jejich počítači "nestraší ve věži".

A konečně – některé počítačové viry a červi, jako například W95/Haiku3, jehož autorem je Španěl Sandman (viz obrázek 8.4.) dokonce vypisují poezii.

Obrázek 8.4

Aktivační rutina viru W95/Haiku.

W95/Haiku se také připojuje k 206.132.185.167 (www.xoom.com v době útoku viru) a používá příkaz GET ke stažení zvukového .WAV souboru (/haiku_wav/Haiku.wav) pro Windows. Tento zvukový soubor uloží jako c:\haiku.wav a následně se přehraje. Haiku demonstruje to, že skutečný, automaticky se šířící kód, nemusí nést payload v sobě – tím pádem může být virus mnohem menší.

8.4 Příležitostně destruktivní payload Jiné viry jsou destruktivní jen příležitostně. Například virus W95/HPS při inicializaci testuje datum a aktivuje se pouze v sobotu. V případě, že uživatel otevře na Windows bitmapový obrázek, virus jej obrátí v horizontálním směru, jak je vidět na obrázku 8.5.

Virus HPS si tyto obrácené obrázky označí vložením ID – DEADBABEh na konec hlavičky bitmapy, čímž zabrání tomu, aby byl obrázek převrácen zpět. To je už poněkud destruktivnější, než aktivační rutina DOSového viru Flip, který sice obrací znaky na obrazovce, nicméně tak činí pouze dočasně. Nezkomprimované bitmapové obrázky jsou v systému Windows používány poměrně často, což často vede k vytvoření nečekaných speciálních efektů – často je potřeba se podívat na obrázky v zrcadle, abychom pochopili jejich význam.

270

Obrázek 8.5

Kapitola 8 – Klasifikace podle payloadu

Aktivační rutina viru W95/HPS.

Existují viry, které útočí na konkrétní spustitelný soubor (většinou se jedná o soubor nějakého antiviru).

Například virus AntiEXE v sobě nese určitý detekční řetězec – virus tedy vyhledá spustitelné soubory, které obsahující tento řetězec a zničí je. Jiné aplikace nikdy nejsou napadeny. AntiEXE je však s největší pravděpodobností retrovirem staršího typu. Retroviry obecně náleží do skupiny mírně destruktivních virů. Obecně útočí na antivirové a bezpečnostní programy, mezi které například patří osobní firewally, které ukončí a následně smaže z disku.

V některých případech viry jednoduše odešlou vybranému programu zprávu "Windows shutdown", čímž donutí zmiňovanou aplikaci ukončit se, protože si myslí, že se vypíná samotný systém Windows.

Samozřejmě – k vypnutí systému vůbec nedojde, nicméně dojde k odstranění ochrany, která by jinak zabránila spuštění útočného programu.

Dalším příkladem lehce destruktivního viru je WM/Wazzu.A. Tento makrovirus byl hodně rozšířen v roce 1996 – hlavně díky skutečnosti, že tímto virem byla napadena jak webová stránka společnosti Microsoft, tak i velké množství CD vydaných touto firmou. Wazzu náhodně poškodí tři slova v dokumentu a vloží slovo wazzu. Morton Swimmer z firmy IBM Research publikoval zábavný dokument o tom, jak pomocí internetových vyhledávacích služeb hrát hru "Where is Wazzu?". Díky extrémnímu rozšíření viru Wazzu bylo totiž na internetu poškozeno obrovské množství dokumentů.

8.5 Velmi destruktivní payload Nejnebezpečnějším typem virů jsou ty, které se záměrně snaží poškodit data nebo dokonce hardware.

V dalších bodech si probereme jejich typy.

8.5.1 Viry přepisující data Některé extrémně škodlivé viry jednoduše formátují disky. Virus Michelangelo je jedním z nejznámějších z této kategorie, zejména díky pozornosti médií. Michelangelo nepřemazává celý disk, pouze se

Počítačové viry – analýza útoku a obrana

271

zaměří na první část zaváděcího sektoru (prvních 256 cylindrů). Z tohoto důvodu pak připadal v úvahu únosný pokus o záchranu poškozených dat.

V průběhu let se většina virových výzkumníků stala experty v oboru záchrany různě zasažených dat a systémů. Některé viry jednoduše smažou zaváděcí sektor systému – Master Boot Record (MBR) a tím zabrání nabootování systému. V tomto a mnoha jiných případech odvede dobrou práci například program Norton Disk Doctor. Mnohé firmy zabývající se záchranou poškozených dat si v takových případech poškození disku účtují poplatky podle množství kilobytů, takže vás případný pokus o záchranu dat může vyjít docela draho. Útočná rutina maďarského viru Filler zde již byla zmiňována. Nejenom, že virus smazal obsah FAT tabulky v DOSu, ale také naplnil tyto sektory znaky 01 takovým způsobem, že vykreslil osm velkých smajlíků. Pokud si někdo prohlédl zničený disk v programu Norton DiskEdit, nalezl milé obrázky podobné těm uvedeným na obrázku 8.6.

Obrázek 8.6

Kresba viru Filler ve FAT sektorech.

Aktivační rutina viru byla zašifrována přímo v těle viru a díky tomu nebyla aktivační rutina zdokumentována v mezinárodní popisu tohoto viru. Původní maďarské jméno, Toltogeto bylo navíc přeloženo do angličtiny jako Filler.

Další skupina virů jednoduše maže soubory. Například rodina virů AntiPascal se soustřeďuje na programy Pascalu a rovnou je odstraňuje z disku. Jiné varianty tohoto viru vytváří dočasné (temporary) soubory s atributy skrytý, systémový, pouze ke čtení a zaplňují tak harddisk. Poté manipulují s MBR, aby nebylo možné se nabootovat do systému. Je smutné, že mnozí úspěšní červi, jako například W32/Witty, také používají tuto metodu a rychle ničí obsah zasažených disků – řádově v minutách.

8.5.2 Data Diddlers Termín "data diddler" (datoví podvodníci) vymyslel Yisrael Radai. Fred Cohen tímto výrazem popisuje viry, které neničí data najednou. Místo toho pomalu manipulují s daty na discích. Tento druh poškození je velmi nebezpečný, protože můžete zazálohovat data předtím, než si napadení povšimneme. Zálohy navíc často bývají cyklicky nahrazovány za novější, a tak v době detekce viru můžeme být snadno bez použitelných dat.

272

Kapitola 8 – Klasifikace podle payloadu

Mezi prvními viry, které způsobují významné poškození, byl virus Dark_Avenger.1800.A, často nazývaný přezdívkou Eddie. Tento virus byl tak nebezpečný, že první firma, kterou jsem navštívil v Maďarsku jako mladý výzkumník sbírající vzorky virů, se o něm zcela odmítla bavit. Vzali napadenou disketu a jednoduše ji připíchli na zeď jako připomínku virového útoku.

Je zřejmé, že Eddie byl pojmenován podle textu, který je uschován uvnitř viru, a který je náhodně zapisován na disk, kromě oblasti FAT tabulky, což zapříčiní pomalou smrt systému. To, že virus nenapadá FAT tabulku, má své dobré důvody – aby se virus mohl déle šířit.

Virus zapisuje text "Eddie lives...somewhere in time" na náhodně vybrané sektory disku. Text je možné později najít, nicméně v době detekce už většinou bývá napadeno velké množství souborů.

Dalším dobrým příkladem "data diddler" viru je Ripper (který byl pojmenován podle Jacka Rozparovače). Ripper vyměňuje dvě slovní hodnoty v náhodně vybraných sektorech a výsledek zapisuje zpátky na disk. To už je vážné poškození! Kromě toho jsme v několika vzácných případech zaznamenali drobné mutace virů na systémech infikovaných virem Riddler. Ve většině případů je výsledkem takové manipulace s daty nefunkční virus, ale teoreticky může dojít k pozměnění ve funkční variantu, kterou (díky této změně) není možné nalézt antiviry používajícími stejnou definici viru (v případě původní varianty).

Ruský virus WordSwap používá podobnou metodu a náhodně prohazuje dvě textová slova, pokud jsou soubory zapisovány na disk.

8.5.3 Viry šifrující data: dobří, zlí a oškliví Virus Disk Killer byl prvním z řady virů používajících k útoku na data šifrování. Disk Killer je bootovací virus a poprvé byl nalezen ve Spojených státech amerických v červnu 1989. Virus se šířil divoce v Evropě o několik měsíců později. Je-li systém zhruba 48 hodin po infekci restartován, virus aktivuje svůj payload, který zobrazí zprávu a znepřístupní obsah disku pomocí jednoduchého XOR šifrování (počínaje zaváděcí tabulkou disku). Výsledkem je systém, který se nedá spustit. Uživatel na obrazovce uvidí toto: Disk Killer — Version 1.00 by COMPUTER OGRE 04/01/1989Warning !!

Don’t turn off the power or remove the diskette while Disk Killer is Processing!

PROCESSING Poté, co virus dokončí šifrování, zobrazí tuto hlášku: Now you can turn off the power.

I wish you luck !

Použitý způsob šifrování byl slabý a záchrana dat byla možná s využitím speciálního dekódovacího programu4. Virus bohužel obsahoval několik drobných chyb ve svém šifrovacím kódu, takže záchrana byla možná pouze v některých případech.

Další bootovací virus, KOH, byl vyvinut v roce 1993. Používá šifru IDEA pro zakódování disku a poté se uživatele zeptá na heslo. Přestože je styl šifrování podobný šifrování použitém ve viru Disk Killer, jeho účelem není držet data uživatele jako rukojmí, nebo je dokonce ničit, ale přesně pravý opak – chránit je. To je také to, čím virus upoutal pozornost a byl popisován jako takzvaný "dobrý virus". Mark Ludwig

Počítačové viry – analýza útoku a obrana

273

tuto ideu zpopularizoval ve své knize, která byla v roce 19955. Ale naneštěstí uveřejnil zdrojové kódy tohoto viru a proto není vůbec překvapením, že dnes existují tucty variant tohoto viru6.

Jiné viry, jako například slovenský virus One_Half, který se objevil v roce 1994, používají jinou techniku. One_Half pomalu šifruje disk pomocí jednoduché metody. Dokud je virus aktivní v paměti, poskytuje dojem přístupnosti disku tím, že zakódovaná data dekóduje dle potřeby. A jakmile je zašifrována přesná polovina disku, zobrazí virus tuto zprávu: Dis is one half.

Press any key to continue... Šifrování viru One_Half je jistým druhem symbiózy mezi systémem a virem samotným. Autor viru si nepřál, aby byl jeho výtvor snadno odstranitelný. Poté, co někdo dokončí nekompetentní ruční opravu (jako například přepsání MBR), disk zůstane stále zakódován a uživatel tak pravděpodobně přijde o data. Mnohé antivirové firmy sice namítaly, že dostupná oprava virového kódu je dostačující, přičemž samotnou opravu porušených dat už – logicky – nezajišťují. Uživatelé měli samozřejmě jiný názor a antivirové firmy nakonec následovaly postup SAC (Slovakian Antivirus Center), která poskytla opravný nástroj pro dekódování disku a odstranění viru z MBR a souborů.

Podobný způsob útoků byl také k vidění u Win32, nicméně s menším úspěchem. Inspirován úspěchem viru One_Half v prosinci roku 1999, se virus W32/Crypto pokoušel zakódovat obsah souborů DLL pomocí Microsoft Crypto API a silného šifrování. Program byl bohužel hodně závislý na použitých verzích Windows a také – díky drobným chybám – docházelo k pádům systému.

Samozřejmostí jsou trojské koně, jako například ten, který v roce 1989 zpřeházel uživatelská data ve snaze vynutit si odměnu od napadených uživatelů za zpřístupnění dat. Tento typ útoku byl také popisován v jedné knize věnované "krypto" virům. Autoři knihy dokonce uvedli, že vytvořili podobný virus na systému Mac, nicméně bylo pro ně "prioritou" tento virus neuveřejnit7.

Podobné krypto viry používají veřejný klíč útočníka, takže uživatel nemá šanci data dekódovat. Často jsou dokonce vyzváni, aby zaplatili určitou částku za dekódování dat. V pravém kontrastu vůči tomuto jsou jednoduché symetrické šifry, které je možné snadno dekódovat díky tomu, že kompletní šifrovací algoritmus, který je obsažen uvnitř těla viru, se dá vyextrahovat.

8.5.4 Ničení hardware V závislosti na výrobci existuje možnost updatovat BIOS pro základní desku počítače. V současnosti používá většina počítačů typ BIOSu, který může být snadno updatován. Na počátku devadesátých let antiviroví výzkumníci předpovídali možnost útoku počítačových virů na tento druh BIOSu. Nechvalně proslulý taiwanský virus nazvaný jako W95/CIH zničil přinejmenším 10000 počítačů tím, že jim přepsal kód zavaděče pro BIOS. Virus pro přístup k BIOSu použil příkazy I/O portu v režimu jádra.

Podobné příkazy sice bylo možné použít i v uživatelském režimu, nicméně to by usnadnilo obranu, a tomu se chtěl autor viru zjevně vyhnout. Například – ovladač v režimu jádra se může zavěsit na I/O porty a používat sekvenci typu "Sezame, otevři se!" pro přístup k zápisu do flash BIOSu. Další možností by bylo zachytávat požadavky v uživatelském režimu s využitím VxD (virtuálního ovladače zařízení),

274

Kapitola 8 – Klasifikace podle payloadu

což by výrazně snížilo riziko možného poškození. Ovšem díky použití příkazů I/O v režimu jádra není možné virus W95/CIH tímto způsobem blokovat.

Je pochopitelné, že mnohem větší výzvou by bylo vytvoření viru, který by přímo napadal Flash BIOS. Virus napsaný autorem jménem Qark v roce 1994 dokazuje, že to možné je. Naštěstí pro uživatele jsou podobné viry příliš závislé na konkrétním typu biosu a je tak obtížné vytvořit obecně fungující virus.

Jednodušší aktivační rutiny dokáží změnit heslo v CMOS na náhodně vygenerované znaky. Těmito útoky je známá rodina virů AntiCMOS. Virus tak donutí uživatele otevřít case počítače a buď odpojit napájecí baterii nebo na chvíli sepnout patřičný přepínač (u novějších desek).

8.6 Útoky DoS – odmítnutí služby V minulosti výzkumníci předpokládali, že cílené útoky na jednotlivé počítače nebo společnosti nejsou pomocí počítačových virů možné. Ale díky moderním operačním systémům a sítím propojujícím celý svět mají útočníci (s například politickými důvody) možnost provádět úspěšné útoky proti konkrétním odvětvím, jako například bankovním institucím.

V minulosti jsme zaznamenali mnoho úspěšných DoS útoků, které byly většinou způsobeny počítačovými červy. Většina z těchto útoků nebyla zaměřena proti konkrétní organizaci. Přesto však zátěž generovaná v síti při jejich šíření byla tak značná, že ji bylo možné považovat za formu DoS útoku. Červ W32/Slammer byl typickým případem nezamýšleného DoS útoku. Tento červ byl sice malý, ale vyznačoval se poměrně agresivním šířením na síti. Po propuknutí masivnějšího šíření byla různá internetová zařízení (jako například routery) těžce přetížena, výsledkem čehož byla až 90% ztráta paketů v některých lokacích a tedy dosti nefunkční provoz sítě. V průběhu útoku byla síť zahlcena a zpomalena natolik, že nebylo možno používat ani textové služby jako e-maily. W32/Slammer navíc rozesílal pakety tak rychle, že způsobil výpadky ATM, zrušené lety a rozdíly ve volebních výsledcích8.

14. srpna mnozí analytici spekulovali o tom, že rozsáhlé výpadky elektrické energie v USA a Kanadě mohly být následkem šíření červa W32/Blaster. Blaster tehdy řádil jako utržený ze řetězu už třetí den.

Oficiální zprávy tyto dohady popřely. Červ Blaster určitě nebyl primární příčinou výpadků. Přesto však měl určitý potenciál k tomu přispět – díky zpomalení komunikace mezi řídícími centry elektráren. Tím pádem neměli síťoví operátoři včas přesná data a nemohli tak zabránit dalším energetickým špičkám. Zprávy uvádějí, že řídící centra elektráren měla "potíže s počítači," což dobře zapadá do možnosti infekce červem9. Výsledkem bylo to, že bylo bez elektřiny celé východní pobřeží, včetně města New York.

Infekce červem Blaster probíhaly tak rychle, že zranitelné systémy neměly šanci se připojit (pokud nebyly chráněny osobním firewallem) k jiným serverům, aby si stáhly bezpečnostní záplaty, protože tyto servery byly rovněž infikovány červem. Blaster se pokoušel zaútočit na webové stránky Microsoftu s Windows Update, nicméně útočník nezvolil správný cíl, a proto nebyl útok proti skutečné stránce úspěšný. Je zjevné, že pokud by útok proti Windows Update byl úspěšný, byly by opravy napadených systémů značně zkomplikovány (díky výrazně ztíženému nahrávání updatů). Argumentem bohužel může být i to, že obtížnost stažení updatů silně nahrávala možnosti být infikován dříve, než mohly být patche staženy a nainstalovány.

Počítačové viry – analýza útoku a obrana

275

16. července 2001 se čínský červ W32/CodeRed pokusil o cílený DoS útok proti stránce www.whitehouse.gov (s IP adresou 198.137.240.91) opakovaným připojováním se k ní. Reakcí na tento útok byla rychlá změna IP adresy. Nicméně červ obsahoval další payload, který byl zaměřen na systémy používající kódovou stránku U.S. English (0x409).

V takovém případě červ nainstaloval rutinu, která se zavěsila na funkci TcpSockSend() modulu INFOCOMM.DLL, která je součástí Microsoft IIS. Zavěšením této rutiny červ neumožnil na napadeném systému přistupovat k jakémukoliv obsahu v HTML. Namísto toho vždy červ zobrazil stránku uvedenou na obrázku 8.7.

Obrázek 8.7

Aktivační rutina červa CodeRed.

Pravděpodobně nejznámějším červem na operačním systému Linux je Linux/Slapper. (Detailnější technické informace ohledně dříve popisovaných červů – a také o mnoha dalších – jsou uvedeny v kapitolách 9 a 10.) Pro úplnost je zajímavé zmínit to, že Slapper byl naprogramován k tomu, aby vytvořil peer-to-peer síť (P2P) napadených počítačů a s její pomocí prováděl DDoS útoky (distribuované útoky odmítnutím služby). Toto umožňovalo útočníkovi se připojit k napadenému uzlu a kontrolovat všechny infikované "zombie" systémy připojené k tomuto uzlu, přičemž bylo možné z jedné lokace okamžitě posílat příkazy všem najednou. Každá kopie červa v sobě nesla rozhraní, které umožňovalo útočníkovi spouštět různé typy DoS útoků, včetně mnoha různých "floodovacích" technik. Přestože bylo nalezeno několik nepřipojených sítí, největší síť se skládala z téměř dvaceti tisíc infikovaných systémů trpělivě čekajících na příkazy útočníka.

Díky červům bylo vytvořeno mnoho dalších způsobu DoS útoků. Dobře to demonstrují například útoky na telefonní číslo 911, které jsou běžným příkladem payloadu počítačových virů (911 je nouzové telefonní číslo ve Spojených státech, obdoba našeho 112). Červ Neat (uváděný v kapitole 3), je na WebTV systémech společnosti Microsoft typickým představitelem takového útoku. Červ jednoduše nastaví systém WebTV tak, aby místo obvyklého telefonního čísla poskytovatele internetu vytáčel číslo 911.

276

Kapitola 8 – Klasifikace podle payloadu

8.7 Získávání peněz pomocí virů Novodobý útočník dokáže pomocí virů i získávat peníze. Přestože profesionální útočníci mohou získávat peníze pomocí průniků do individuálních systémů, kde kradou čísla kreditních karet a další cenná data, počítačový červ může v nesrovnatelně kratším čase zasáhnout mnohem více cílů najednou a zvýšit tak šance na to, že útočník získá cenná data, aniž by po sobě zanechal stopu.

8.7.1 Phishing Existuje mnoho způsobů, pomocí kterých mohou počítačoví červi získávat informace. Nejjednodušším případem je použití sociálního inženýrství (často nazýváno jako "phishing") a sbírání informací pomocí prostého dotazu žádajícího například data o vaší kreditní kartě a číslo PIN. V případě phishingu jsou nejčastěji používány podvržené e-maily a podvodné stránky, které jsou navrženy k oklamání adresáta. Útočníci používající phishing jsou schopni přesvědčit zhruba 5% adresátů, aby jim odpověděli10.

Virus W32/Mimail.I@mm11 představuje jednoduchý a přesto poměrně úspěšný příklad útoku. Červ se sám šíří pomocí e-mailových zpráv. Svůj pokus o získání informací maskuje pomocí falešných dialogových oken a předstírá, že se jedná o PayPal (viz obrázek 8.8), který se uživatele ptá na číslo kreditní karty a další osobní informace. Takto získané informace skladuje a po následném zakódování je odešle útočníkovi.

Obrázek 8.8

Dialogové okno zobrazované virem W32/Mimail.I@mm.

8.7.2 Vlastnosti zadních vrátek Červi v sobě často mívají zabudovaná zadní vrátka (backdoors). Příkladem tentokrát bude červ W32/ HLLW.Qaz.A objevený poprvé v červenci 2000 v Číně. QAZ je doprovodný (companion) virus, ale zároveň se šíří sítí. Navíc obsahuje zadní vrátka, která umožní vzdálenému uživateli připojení a kontrolu nad počítačem pomocí portu 7597.

Počítačové viry – analýza útoku a obrana

277

QAZ prochází skrze sdílené NetBIOSy (které jsou slabě chráněny) a snaží se najít počítač vhodný k infekci. Poté, co je vzdálený počítač infikován, pošle červ e-mailem útočníkovi IP adresu tohoto stroje.

Payload zde je v podobě aktivovaných zadních vrátek. To umožní hackerovi převzít kontrolu nad počítačem. Podle různých zdrojů je pravděpodobné, že QAZ stojí za úspěšnými útoky proti sítím Microsoftu, kdy má nezabezpečený domácí počítač vzdálené připojení k firemním sítím, čímž tak umožní útočníkovi přístup k cenným informacím.

Dalším z řady známých případů jsou zadní vrátka zabudovaná ve variantě CodeRed pojmenované jako CodeRed_II. Tento červ kopíruje soubor CMD.EXE ze složky Windows NT\System do následujících složek (pokud existují): C:\Inetpub\Scripts\Root.exe D:\Inetpub\Scripts\Root.exe C:\Progra~1\Common~1\System\MSADC\Root.exe D:\Progra~1\Common~1\System\MSADC\Root.exe

Přestože se CodeRed_II šíří zejména infikováním paměti (stejně jako jeho předchůdce), vypouští navíc trojského koně pod jménem VirtualRoot. Tento po spuštění modifikuje následující klíče registrů: HKLM\System\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots

Trojský kůň přidá několik nových klíčů a nastaví u nich uživatelskou skupinu na hodnotu 217. Tímto umožní útočníkovi ovládat webový server zasláním HTTP požadavku GET na spuštění scripts/root.exe na infikovaném webovém serveru. Pokud je útok úspěšný, můžeme ve správě počítače najít dva nové přístupy k diskům C: a D: (jak je to vidět na obrázku 8.9). Útočník má takto umožněn vzdálený přístup k logickým diskům C: a D: na infikovaném počítači skrze legitimní požadavky na webový server.

Obrázek 8.9

Systém s "otevřeným" sdílením po útoku CodRed_II.

278

Kapitola 8 – Klasifikace podle payloadu

Počítačové viry používají schopnosti zadních vrátek i při útocích na Novell NetWare. Například virus Hypervisor12 pro operační systém DOS obsahoval speciální payload sloužící k vytvoření uživatele Hypervisor, který měl oprávnění jako uživatel Supervisor na serverech Novell NetWare v roce 1995.

Hypervisor vyčkával v systému tak dlouho, dokud se do této sítě nepřihlásil uživatel Supervisor z infikovaného stroje. V tom okamžiku byl virus schopen přidat nového uživatele a pomocí atributu SUPERVISOR SECURITY_EQUALS mu doplnit potřebná práva. Protože uživatel Hypervisor neměl nastavené heslo, mohl se útočník přihlásit zanedlouho poté, co se dostal virus do sítě. Hypervisor také kopíruje do složky SYS:LOGIN/ soubory databáze objektů Novell NetWare. Jedná se o soubory NET$BIND.SYS, NET$BVAL.SYSv případě serverů řady 2.xx a o soubory NET$OBJ.SYS, NET$PROP.SYS v případě serverů řady 3.xx. Hypervisor patří do skupiny stealth virů.

Další červi, jako například Nimda, používají podobný přístup na systémech Windows. Nimda přidá účet Guest do administrátorské skupiny, čímž získá účet Guest administrátorská práva.

Dalším příkladem je rodina W32/Bugbear@mm, která se šíří celou řadou způsobů včetně masového rozesílání e-mailů, infekcí přes síťové sdílení a souborovou infekcí. Některé varianty Bugbear navíc podporují komponenty zadních vrátek a funkci sledování stisknutých kláves. Pomocí této funkce červ sbírá všechny informace, které uživatel vkládá skrze klávesnici do počítače, čímž může získat opravdu citlivá data. Sesbírané informace červ posílá na různé e-mailové účty patřící útočníkovi. Pomocí zadních vrátek se útočník může ke zkompromitovaným systémům připojovat vzdáleně. Některé verze Bugbear specificky útočí na finanční instituce. Červ obsahuje obsáhlý seznam více než 1000 doménových jmen patřících bankám po celém světě. Když Bugbear zjistil, že výchozí e-mailová adresa lokálního systému patří bankovní společnosti, zasílal data získaná sledováním stisknutých kláves, společně s přihlašovacími údaji vytáčeného připojení, na e-mailový účet útočníka. Tvůrce viru nepochybně plánovat využít tyto informace k připojení do sítě finanční instituce za účelem vlastního obohacení.

8.8 Závěr Dá se předpokládat, že online podvody se budou s rostoucím počtem počítačových červů stávat stále běžnějšími. V ohrožení jsou kromě bank i makléřské firmy. Představte si možný chaos na finančních trzích způsobený červem, který by svévolně "nakupoval a prodával" obchodovatelné akcie. Hlavní akcie se často obchodují v objemech desítek milionů akcií denně, cena se ovšem během dne málokdy změní zásadním způsobem. Rovnováha mezi kupujícími a prodávajícími je obvyklá – nikoliv však v případě, pokud by byl počítačový červ použit k náhodnému (popř. cílenému) nákupu nebo prodeji akcií jménem tisíců infikovaných uživatelů.

Existuje patrná snaha spammerů využívat počítačové červy a různá zadní vrátka pro finanční obohacení se na úkor někoho jiného.

Počítačové viry – analýza útoku a obrana

279

Odkazy 1. Thomas A. Longstaff a E. Eugene Schultz, "Beyond Preliminary Analysis of the WANK and OILZ Worms: A Case Study of Malicious Code", Computers & Security, Volume 12, Issue 1, únor 1993, str. 61-77.4.

2. Mikko Hypponen, "Virus Activation Routines", EICAR, 1995, str. T3 1-11.

3. Peter Szor, "Poetry in Motion", Virus Bulletin, duben 2000, str. 6-8.

4. Fridrik Skulason, "Disk Killer", Virus Bulletin, leden 1990, str. 12–13.

5. Mark Ludwig, "Giant Black Book of Computer Viruses", American Eagle Publications, Inc., 1995.

6. Vesselin Bontchev, "Are ‘Good’ Computer Viruses Still a Bad Idea?", EICAR, 1994, str. 25-47.

7. Dr. Adam L. Young a Dr. Moti Yung, "Malicious Cryptography: Exposing Cryptovirology", Wiley Publishing, Indianapolis, 2004, ISBN: 0764549758.

8. Gerald D. Hill III, "The Trend Toward Non-Real-Time Attacks", Computer Fraud & Security, listopad 2003, str. 5-11.

9. Bruce Schneier, "Blaster and the Srpen 14th Blackout", http://www.schneier.com/crypto-gram-0312.html.

10. Anti-Phishing Working Group, http://www.antiphishing.org/.

11. Stuart Taylor, "Misguided or Malevolent? New Trends In Virus Writing", Virus Bulletin, únor 2004, str. 11-12.

12. Peter Szor a Ferenc Leitold, "Attacks Against Servers", Forraskod, březen/duben 1995, str. 2-3.

280

Kapitola 8 â&#x20AC;&#x201C; Klasifikace podle payloadu

KAPITOLA 9 Strategie počítačových červů

"Červ: forma programu schopná vlastní replikace a šíření skrze počítačovou síť. Typicky spojená se škodlivými účinky."

– Stručný Oxfordský anglický slovník, revidovaná desátá edice

282

Kapitola 9 – Strategie počítačových červů

9.1 Úvod Tato kapitola se zabývá rozborem generické ("typické") struktury pokročilého počítačového červa a běžnými strategiemi, které červ používá k napadení dalších systémů. Počítačoví červi se primárně šíří skrze sítě, ale svým způsobem reprezentují podtřídu počítačových virů. Ve skutečnosti je to tak, že ani samotní výzkumníci ve sdružení CARO (Computer Antivirus Researchers Organization, Organizace antivirových výzkumíků) nemají jednotný pohled na to, co má být přesně označeno jako "červ." Přáli bychom si dosáhnout jednotného názoru, ale někteří z nás se dokonce domívají, že červi jsou jenom pouhé viry1.

Toto se dále pokusím vysvětlit.

Infekce orientovaná především na strategii průniku skrze síť je jistě nejmarkantnějším rozdílem mezi viry a červy. Červi obvykle ani nepotřebují infikovat soubory, jako to dělají viry, protože se šíří jako samostatné programy. Mnozí červi navíc mohou, pomocí vzdáleného přístupu, převzít kontrolu nad počítačem, a to bez jakéhokoliv přispění uživatele, například využitím slabiny nebo dokonce jejich většího množství. Tyto obvyklé charakteristiky však nejsou vždy spolehlivým vodítkem. Tabulka 9.1 ukazuje některé dobře známé případy.

Tabulka 9.1 – Dobře známé typy a metody počítačových červů.

Jméno / Objeven

Typ

Infikuje

Metoda průniku

WM/ShareFun, únor 1997

Na programu Microsoft Mail závislý e-mailový program

Dokumenty MS Word verze 6 a 7

Díky uživateli

Win/RedTeam, leden 1998

Modifikuje odchozí e-maily programu Eudora

Windows NE soubory

Díky uživateli

W32/Ska@m(Happy99Worm), leden 1999

32-bitový Windows červ-mailer

WSOCK32.DLL (vložením malé funkce zpětného volání)

Díky uživateli

W97M/Melissa@mm, březen 1999

Červ masově rozesílající e-maily pomocí MS Word 97

Různé dokumenty MS Word 97

Díky uživateli

VBS/LoveLetter@mm2, květen 2000

Červ masově rozesílající e-maily skriptem Visual Basicu

Přepisuje soubory VBS svými kopiemi

Díky uživateli

W32/Nimda@mm Září 2001

32-bitový Windows červ, který masově rozesílá e-maily a spouští je

32-bitové PE soubory

Využívá zranitelná místa a spouští se cíleně sám

Tabulka 9.1 napovídá, že infekce souborů je poměrně obvyklá technika mezi úspěšnými prvotními počítačovými červy. Podle jedné z definic červa plyne, že červ musí být soběstačný, musí se šířit vcelku a nesmí být závislý na připojování se k hostitelským souborům. Přesto však tato definice neznamená, že by se červ nemohl chovat jako klasický infektor souborů (jako vylepšení způsobů jeho šíření).

Počítačové viry – analýza útoku a obrana

283

Existuje množství červů, jako například Morris3, Slapper4, CodeRed, Ramen, Cheese5, Sadmind6 a Blaster, kteří nepoužívají strategii infekce souborů, ale jednoduše infikují nové uzly v síti. Proto také různé obranné metody zaměřené na ochranu před červy musí být soustředěny na ochranu sítě samotné a uzlů k ní připojených.

9.2 Generická struktura počítačových červů Každý počítačový červ má několik zásadních komponent jako třeba vyhledávač obětí nebo modul pro šíření infekce a množství dalších modulů, jako třeba vzdálené ovládání, rozhraní pro aktualizace, plánovač životního cyklu a rutiny pro payload.

9.2.1 Vyhledávač obětí Aby se červ mohl pomocí sítě šířit co nejrychleji, potřebuje být schopen lokalizovat eventuální možné oběti. Většina červů prohledá počítač ve snaze najít e-mailové adresy, přičemž se na tyto adresy následně odešle. To je pro útočníky výhodné, protože společnosti obvykle potřebují, aby e-maily procházely přes firemní firewally, čímž červům poskytují snadný vstupní bod.

Mnoho červů disponuje technikami pro prohlížení sítě a vyhledávání uzlů na úrovni IP a dokonce otisku (fingerprint) vzdáleného systému pro kontrolu, zdali je systém napadnutelný.

9.2.2 Modul pro šíření infekce Velmi důležitou složkou počítačového červa je strategie, pomocí které se červ dostává do dalšího uzlu, aby získal kontrolu nad vzdáleným systémem. Většina červů předpokládá přítomnost určitého operačního systému, jako například počítač s MS Windows a rozesílá červy kompatibilní s těmito systémy. Autor viru může pro útok použít například nějaký skriptovací jazyk, nějaký formát dokumentu, spustitelný souboru nebo kód vložený do paměti (nebo kombinaci zmiňovaných způsobů). Ke spuštění červa jsou pak uživatelé lákáni pomocí různých technik sociálního inženýrství. V dnešní době však stále více červů začíná dávat přednost využití různých exploitačních modulů, které jej spustí automaticky. Využívání zranitelných míst je obsahem kapitoly 10.

Poznámka Zdá se, že někteří "mini-červi" jako třeba W32/Witty a W32/Slammer mají v jedné funkci umístěný vyhledávač oběti (skenování sítě) a modul pro šíření infekce. Přesto však stále obsahují některé nevšední vlastnosti – generování náhodných IP adres a šíření svého tělo do nových obětí.

9.2.3 Vzdálené ovládání a rozhraní pro aktualizaci Použití vzdáleného ovládání pomocí komunikačního modulu je další důležitou součástí červa. Bez tohoto modulu by totiž autor nebyl schopen ovládat síť červů pomocí řídících příkazů. Takové vzdálené ovládání pak umožňuje útočníkovi používat červa jako nástroj umožňující DDoS (distributed denial of service, distribuovaný útok odmítnutím služby)7 pomocí síťových "zombií" proti libovolným cílům.

Kapitola 9 – Strategie počítačových červů

284

Aktualizační nebo plug-in rozhraní je důležitou součástí vyspělých červů, protože umožňuje aktualizaci kódu červa na již kompromitovaném systému. Běžným problémem je to, že poté, co je systém infikován pomocí konkrétního exploitu, není už možné červa aktualizovat prostřednictvím stejného exploitu.

Takto se může útočník vyhnout případné havárii, která by mohla nastat při vícenásobné infekci tohoto uzlu. Je pochopitelně možné najít další způsoby zabraňující takové vícenásobné infekci.

Aktualizace červa má obvykle vést ke změně jeho chování nebo posílání nových infekčních strategií, aby bylo možné kompromitovat co nejvíce uzlů. Rychlé zavedení zdroje nákazy je obzvláště nebezpečné.

Příkladem může být případ, kdy útočník použije jeden druh exploitu během prvních 24 hodin po infikování systému a pak s pomocí aktualizačního rozhraní červa vytvoří další exploity.

9.2.4 Plánovač životního cyklu Někteří autoři viru nechávají konkrétní verzi počítačového červa běžet pouze po určitou časovou periodu. Na příkladu červa W32/Welchia můžeme vidět, jak červ počátkem roku 2004 "spáchal sebevraždu", aby pak byla na konci února 2004 uvedena další varianta tohoto viru, označená jako Welchia/B, která byla v provozu zhruba 3 měsíce. Na druhou stranu – nebývá vůbec neobvyklé, když mají červi chyby ve svých plánovačích životního cyklu, díky kterým se nikdy nezastaví. Dokonce se často setkáváme s variantami počítačových červů upravených třetí osobou tak, aby k autodestrukci nikdy nedošlo.

Prohlédněte si statistiku získanou od Frederika Perriota, která ukazuje časové období mezi srpnem 2003 a únorem 2004 (je zobrazena na obrázku 9.1). Náhlý pokles aktivity červa Welchia souvisí s plánovačem životního cyklu, který spustil autodestrukční rutinu.

Welchia pings/attackers from August 24th, 2003 to February 24th, 2004 180

number of hits/IPs

160 140 120 100 80 60 40 20 0 time Welchia pings

Obrázek 9.1

New IPs

Sebevražda červa Welchia.

Počet systémů útočících pod vlivem červa Welchia dosáhl hodnoty kolem 30 tisíc (viz obrázek 9.2). Pak se červ začal samovolně odstraňovat.

Počítačové viry – analýza útoku a obrana

Obrázek 9.2

285

Vzrůstající počet útočících systémů, které byly pod vlivem červa Welchia.

9.2.5 Payload Další možnou složkou počítačového červa je payload (aktivační rutina). V mnoha případech počítačoví červi neobsahují žádný payload. Nicméně je možné pozorovat vzrůstající popularitu payloadu v podobě DoS útoku na konkrétní weby. Ve většině případů se ovšem jedná o "pouhé" přetížení sítě, jehož příčinou je rozšiřování samotného červa, a nikoli o záměrný DoS útok. Přetíženy bývají především routery8.

Zajímavým vedlejším efektem, který je občas možné pozorovat, je například náhodný útok na síťové tiskárny.

Počítačoví červi také mohou spojit jednotlivé infikované systémy v jeden výkonný superpočítač. Například W32/Opaserv9 se pokouší získat tajný klíč11 založený na šifře DES10 způsobem, který je podobný způsobu, jakým funguje projekt SETI. Dokonce se stává, že někteří počítačoví červi (například W32/Hyd) stáhnou a na kompromitované systémy rovnou nainstalují program SETI. Červ W32/Bymer je příkladem, kdy je na kompromitované počítače instalována aplikace DNETC (Distributed Network Client). Tento způsob útoků byl předpovězen již v roce 198912.

Zajímavostí je snaha o spolupráci dvou počítačových červů jako payload. V oběhu bylo možné spatřit různé "antičervy", kteří bylí vytvářeni a rozšiřováni za účelem ničení počítačových červů a pro instalování záplat proti zranitelnostem, které tito červi zneužívali. Příkladem mohou být červi Linux/Lion versus Linux/Cheese a W32/CodeRed versus W32/CodeGreen. V této kapitole budou dále zmiňovány další způsoby interakce mezi škodlivými programy.

V současné době vzrůstá popularita instalací SMTP (Simple Mail Transfer Protocol, protokol pro přenos pošty) jako projev rutiny červa. Spammeři za použití červů typu W32/Bobax kompromitují systémy ve velkém měřítku a pak používají červem vytvořený SMTP server k rozesílání nevyžádané pošty.

286

Kapitola 9 – Strategie počítačových červů

9.2.6 Sledování počtu infikovaných systémů Mnozí autoři virů jsou zvědaví na to, kolik strojů se jim podařilo infikovat. Alternativou je případ, kdy chtějí ostatním umožnit sledování trasy virové infekce. Některé viry, jako například W97M/Groov.A13, ukládají informaci o IP adrese infikovaného systému na FTP. Počítačoví červi obvykle útočníkovi odesílají e-mailovou zprávu s informacemi o infikovaném počítači, aby mu umožnili sledovat šíření. Například červ Morris obsahuje rutinu, která se pokouší po každých patnácti infekcích odeslat UDP datagram na adresu ernie.berkeley.edu. Rutina je bohužel nefunkční, takže k odeslání informací nikdy nedojde14. V kapitole ještě později uvedu několik dalších příkladů ohledně sledování počtu infikovaných systémů.

9.3 Vyhledávač obětí Efektivní vyhledávač další oběti je modul, který má pro počítačového červa velkou důležitost. Nejjednodušším mechanismem je sběr e-mailových adres z počítače, na kterém červ běží, přičemž se na tyto adresy odesílá v přílohách. Existují však mnohem sofistikovanější metody, schopné najít oběti rychleji, jako například náhodné vytvoření IP adresy spojené s následným skenováním portů.

Moderní počítačoví červi používají k útokům nejrůznější protokoly. V následujících částech se pokusím shrnout nejdůležitější typy útoků a techniky pro skenování sítě.

9.3.1 Sklízení e-mailových adres Je mnoho způsobů, jak může červ sbírat e-mailové adresy pro další útoky. Útočník může adresy získávat ze standardních API knihoven, včetně COM rozhraní15. Příkladem tohoto může být W32/Serot16.

Soubory bývají prohledávány přímo, nicméně pokročilejší červi často používají NNTP (network news transfer protocol) ke čtení diskusních konferencí nebo rovnou prohledávají internetové vyhledávací služby (jako Google) pro nalezení e-mailů s využitím technik, které jsou podobné těm, kteří používají spammeři.

9.3.1.1 Červi a adresáře Každé počítačové prostředí používá nějakou formu adresáře obsahující kontaktní informace. Například, v systému Windows je to program Adresář obsahující e-mailové adresy vašich přátel, kolegů a klientů, nebo také jména e-mailových diskusních konferencí, kam posíláte příspěvky. Pokud se červ dostane k informacím uloženým na těchto místech, může poslat sám sebe (jako přílohu) na všechny zde uvedené e-maily a šířit tak infekci exponenciální řadou. Získávání informací z podobných adresářových programů je triviální záležitostí.

S touto technikou byl v březnu 1999 obzvláště úspěšný červ W97M/Melissa@mm17. Funkce tohoto červa jsou závislé na instalaci Microsoft Outlooku a šíří se pomocí e-mailu, který jako přílohu obsahuje infikovaný dokument typu Word.

Počítačové viry – analýza útoku a obrana

287

9.3.1.2 Útoky založené na analýze souborů na disku Různí počítačoví červi, jako například W32/Magistr18, vyhledávají soubory e-mailových klientů nebo soubory s koncovkou WAB. V těchto souborech pak pátrají po e-mailových adresách. Tato technika zůstala populární i poté, co Microsoft představil nové bezpečnostní funkce programu Outlook, které byly zaměřeny právě proti červům šířícím se pomocí e-mailů.

Jak asi očekáváte, útoky založené na zpracování souborů na disku mají mnohé nedostatky. Například, mnozí červi zvládají pouze určité formáty souborů. Adresář systému Windows má v různých verzích programu různé formáty souborů. Často nebývá často podporováno Unicode. V takovém případě červ nemá možnost se dále šířit. Podobné problémy jsou rušivé zejména při laboratorních testech infekcí. Je to typický zákon schválnosti – přestože je celý svět napaden určitým červem, tento červ odmítá fungovat ve vašem laboratorním prostředí.

Nicméně, tato technika se ukazuje v reálném světě jako dostatečně účinná a mnohé útoky červů jsou toho důkazem. Například červ W32/Mydoom@mm, který se hodně rozšířil na počátku roku 2004, prohledával soubory s těmito příponami: HTM, SHT, PHP, ASP, DBX, TBB, ADB, PL, WAB a TXT. Počítačoví červi často používají heuristiku ke zjištění, zdali je určitý řetězec e-mailovou adresou. Jedna z možných heuristik je vyhledávání řetězce "mailto:" v HTML souborech, přičemž je možné očekávat, že bude následován e-mailovou adresou. Občas bývá omezena délka jména domény. Například řetězec nekdo@a.cz nebude červ typu W32/Klez.H považovat za správnou e-mailovou adresu, protože část "a.cz" je příliš krátká na to, aby byla funkční (přestože je možné takovou doménu v lokální síti provozovat). Někteří červi navíc útočí pouze na adresáty s určitým specifickým jazykem, jako je například maďarština, a proto kontrolují doménu nejvyšší úrovně (TLD) e-mailové adresy. Červ Zafi.A se odesílá pouze na adresy, které mají koncovku ".hu" (Maďarsko)19. Červ Sircam20 vyhledává e-mailové adresy v adresáři Cache programu Internet Explorer, v adresáři Personal, a také v adresáři, který obsahuje program Adresář pro Windows. Prohledává soubory, které začínají slovy "sho", "get" nebo "hot", nebo jejichž přípona je .HTM nebo .WAB.

9.3.1.3 Získávání e-mailů založené na NNTP Útočníci již dlouho představují své výtvory v internetových diskusních skupinách. Takový News Net byl velmi intenzivně zneužíván kolem roku 1996. Důsledkem toho bylo, že výzkumníci stojící za antivirem Dr. Solomon se rozhodli vytvořit službu nazvanou jako Virus Patrol21, která skenovala zprávy Usenetu na přítomnost známých a potenciálně neznámých druhů škodlivého softwaru, kterými byly zprávy nepřetržitě zaplavovány. Virus Patrol byl představen v prosinci 1996.

NNTP je možné používat mnoha škodlivými způsoby. Útočník může například použít news server k vytvoření rozsáhlé lokální databáze e-mailů čítající až milion lidí. To může útočníkovi hodně pomoci v úvodní fázi šíření červa.

Toto je běžná technika spammerů a je podezření, že někteří červi, jako například rodina W32/Sobig, byli rozšířeni s využitím podobné techniky. Sbírání e-mailových adres z internetových diskusních skupin není neznámým pojmem ani mezi Win32 viry. Jeden z úplně prvních známých virů pro Win32 totiž používal e-mail ke svému šíření s využitím NNTP. W32/Parvo22 byl představen na konci roku 1998

288

Kapitola 9 – Strategie počítačových červů

nechvalně proslulým autorem virů jménem GriYo, který je členem skupiny 29A. Není překvapením, že stejně – jako další viry od tohoto autora – používá polymorfismus pro infekci PE souborů, nicméně se mu nedá upřít prvenství v tom, že to byl první virus, který měl ve svém těle integrován engine pro hromadné rozesílání emailů pomocí SMTTP. Virus Parvo předběhl svoji dobu o celé roky. Tělo viru bylo napsáno v čistém assembleru a mělo velikost pouhých 15 kB. W32/Parvo využíval různé newsgroup k získávání e-mailových adres, ale jeden drobný problém výrazně omezil jeho šíření. Parvo se totiž náhodně pokoušel připojovat ke dvěma news serverům – talia. ibernet.es nebo diana.ibernet.es. Tyto servery však v té době nebyly přístupné úplně každému. Proto bylo získávání e-mailových adres viru Parvo omezeno hranicemi Španělska.

Parvo se připojoval pomocí portu 119/TCP (NNTP) k jednomu ze zmiňovaných serverů a započal komunikaci. Útočník připravil celkem tři různé e-mailové zprávy s obsahem, u kterého očekával, že bude dostatečně zajímavý pro čtenáře těchto newsgroup.

Parvova první zpráva byla zaměřena na pravidelné čtenáře newsgroup zaměřené na hacking, jako třeba alt.bio.hackers, alt.hacker, alt.hackers, alt.hackers.malicious atd. Druhá zpráva byla odesílána na podseznam tohoto seznamu newsgroupů. A konečně – třetí zpráva byla zaměřena na návštěvníky erotických newsgroups, jako třeba alt.binaries.erotica, alt.binaries.erotica.pornstar atd.

Aby Parvo v těchto newsgroups našel e-mailové adresy, používal příkaz group, díky kterému se náhodně připojoval ke skupinám a poté pomocí příkazů head a next náhodně vkládal náhodný počet zpráv.

Nakonec vyextrahoval e-mail z hlavičky náhodně vybrané zprávy a tento proces dále opakoval.

9.3.1.4 Získávání e-mailových adres z webu Útočníci často pro získávání e-mailových adres používají různé vyhledávací služby. To je poměrně snadný způsob, pomocí kterého může útočník rychle získat přístup k velkému množství adres. V době psaní této knihy bylo možné najít první červy, kteří zneužívají populární vyhledávací služby jako například Google, Lycos, Yahoo! nebo Altavistu k získávání e-mailových adres. Například červW32/Mydoom.

M@mm používal tuto techniku tak intenzivně, že (dle vyjádření společnosti Google) způsoboval drobné DoS útoky proti jejich serverům.

9.3.1.5 Získávání e-mailových adres pomocí ICQ Někteří počítačoví červi, jako například polymorfní W32/Toal@mm23 sbírají e-mailové adresy pomocí tzv. "Bílých stránek" (whitepages) umístěných na stránkách programu ICQ. Například adresa http:// www.icq.com/whitepages umožňovala vyhledávání uživatelů na základě různých charakteristických znaků, jako jméno, přezdívka, pohlaví, věk či země původu. Po vzájemném kombinování těchto údajů bylo k dispozici překvapivě velké množství informací včetně e-mailových adres. Není překvapením, že toho dokázal počítačový červ náležitě zneužít.

9.3.1.6 Sledování přístupu k SMTP a diskusním skupinám za běhu Další metodou, jak může počítačový červ zjistit e-mailové adresy, je prohledávání odcházejících zpráv.

Dokonce i tehdy, když e-mailová adresa není nikde na disku uložena, může červ odeslat svoji kopii na adresu, na kterou uživatel právě odeslal svůj e-mail. Červ Happy9924 byl první, kdo tuto metodu použil.

Počítačové viry – analýza útoku a obrana

289

Tento červ odesílá dvě zprávy, které vypadají podobně jako ukázka na obrázku 9.3. Všimněte si hlavičky, která obsahuje text: X-Spanska: Yes. Toto je metoda, která je využita autorem červa. SMTP servery totiž ignorují příkazy, které začínají písmenem X. Date: Fri, 26 Feb 1999 09:11:40 +0100 (CET) From: "XYZ" <xyz@xyz.cz> To: <samples@datafellows.com> Subject: VIRUS X-Spanska: Yes

Obrázek 9.3

Hlavička e-mailu odesílaného červem Happy99.

Původní zpráva je uvedena na obrázku 9.4.

From: "XYZ" <xyz@xyz.cz> To: <samples@datafellows.com> Subjec: VIRUS Date: Fri, 26 Feb 1999 09:13:51 +0100 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Obrázek 9.4

Zpráva též odesílaná červem Happy99.

Tělo tohoto dalšího e-mailu obsahuje spustitelný soubor pojmenovaný jako happy99.exe. Poté, co jej uživatel spustí, je kód červa aktivován.

Happy99 hledá dvě jména API v exportní části souboru WSOCK32.DLL. Tato dynamická knihovna je komunikačním nástrojem používaným systémem Windows a mnohými dalšími síťovými aplikacemi, včetně několika populárních e-mailových klientů. Červ upraví exportní adresy položek connect() a send() takovým způsobem, aby nasměroval API na nové položky na konci sekce .text (tzv. "slack" prostor) knihovny WSOCK32.DLL. Poté, co je upravená DLL načtena do paměti jako klientská knihovna pro síťové aplikace, červ přerušuje API příkazy connect() a send(). Pokaždé, když dojde ke spojení, červ zkontroluje použitý port. Pokud se ukáže, že patří mezi porty používané pro e-maily, nahraje do adresovacího prostoru procesu novou knihovnu pojmenovanou jako SKA.DLL, která obsahuje kompletní kód červa, který byl předtím uložen na disk.

Když je zavolána přerušená API funkce send(), červ opětovně zkontroluje, zdali je událost spojena s diskusními skupinami nebo e-mailem. Pokud ano, zkopíruje část původní hlavičky e-mailu a dává pozor na klíčová slova MAIL FROM:, TO:, CC, BCC a NEWSGROUPS. A nakonec přidá do hlavičky e-mailu řetězec X-Spanska: YES. Existuje množství červů, kteří používají podobnou techniku jako Happy99.

Někteří z nich vkládají svůj kompletní kód přímo do knihovny WSOCK32.

9.3.1.7 Kombinace metod Samozřejmě, že existuje velké množství variant pro získávání e-mailových adres určených k šíření červů.

Například červ Linux/Slapper 3 je schopen sbírat e-mailové adresy a poskytovat je na žádost útočníkovi

290

Kapitola 9 – Strategie počítačových červů

pomocí vzdáleného ovládáni. Další červ od tohoto autora pak již může využívat databáze e-mailových adres pro své rychlé rozšíření na velké množství strojů, bez nutnosti provádět velké množství úspěšných infekcí za účelem získání e-mailů. Ještě pravděpodobnější ovšem je, že takto získané e-mailové adresy budou útočníkem použity ke spamování.

9.3.2 Útoky založené na prohledávání sdílených prostředků Pravděpodobně nejsnadnější metoda pro nalezení dalších uzlů sítě je prohledávání možných vzdálených připojení. Systémy Windows jsou snadno napadnutelné, protože podporují širokou škálu prostředků umožňujících vyhledávání dalších strojů. Toho využívají počítačové viry k infikování vzdálených cílů, příkladem může být W32/Funlove. Tyto útoky způsobily velké průniky do velkých korporací po celém světě.

Někteří počítačoví červi mají drobné problémy s implementací a staly se až příliš úspěšnými ve vyhledávání sdílených zdrojů, včetně síťových tiskáren. K tomuto došlo proto, že ne každý červ dává pozor na to, jaký typ zdroje prohledává, což může například vést k náhodnému tisku na síťových tiskárnách. Vlastně dochází k tomu, že náhodné binární znaky vypadající jako tištěná data jsou ve skutečnosti kódem červa.

W32/Bugbear a W32/Wangy jsou příklady virů, které náhodně útočí i na síťové tiskárny. Úspěšnost tohoto typu útoku obvykle závisí na stupni důvěry mezi dvěma systémy. Další faktory přispívající k větší úspěšnosti jsou tyto: 

Nevyplněná hesla – Mnohé instalace jsou nechráněné vůči útokům, protože ještě nemají nastavené administrátorské heslo pro přístup ke sdíleným prostředkům.



Slabá hesla: útoky založené na slovnících – Slabá hesla byla cílem počítačových virů již od roku 1988, kdy se začal šířit červ Morris. Přesto se však slovníkové útoky na systémech Windows nestaly populárními až do roku 2003, kdy se objevila celá řada červů s touto funkcí, jako například BAT/Mumu. Je překvapivé, že Mumu obsahoval relativně krátký seznam hesel jako třeba password, passwd, admin, pass, 123, 1234, 12345, 12345 a prázdné (nevyplněné) heslo. Je zřejmé, že za svůj úspěch vděčí spíše nevyplněným heslům na administrátorských účtech.



Slabiny spojené s manipulací s hesly – Červ W32/Opaserv se objevil v září roku 2002 a proslavil se útoky proti systémům, které sice byly chráněny použitím silných hesel, ale sdílely síťové zdroje se zranitelnými instalacemi Windows, které bylo možno napadnout. Konkrétní slabina, kterou Opaserv použil pro průnik, je popsána v bezpečnostním zpravodaji MS00-072 a týkala se systémů Microsoft Windows 95/98 a ME. Tato slabina, která je známá jako zranitelnost hesla sdílených zdrojů (share-level password vulnerability), umožňovala přístup ke sdíleným zdrojům se znalostí prvního znaku hesla, bez ohledu na to, jak dlouhé heslo bylo. Množství systémů, které sdílely síťové zdroje pomocí internetu bez osobního firewallu, bylo opravdu neuvěřitelné a umožňovalo červu snadný přístup ke sdíleným zdrojům, včetně možnosti zápisu.



Útoky postavené na odchytávání hesel s administrátorskými právy – Administrátoři domény mají v sítích Windows právo ke čtení a zápisu na jakémkoliv systému v síti, pokud to není výslovně zakázáno. Systémy založené na NT umožňují administrátorům na dálku spouštět programy a příkazy, které vyžadují práva vyšší úrovně, než mají běžní uživatelé sítě.

Počítačové viry – analýza útoku a obrana

291

Tyto vlastnosti povolují vzdálené ovládání, ale zároveň otevírají celou kapitolu bezpečnostních problémů. Získání práv doménového administrátora není triviální úkol. Přesto však, pokud má červ dostatek času, je tento úkol proveditelný. Červ se může šířit tradičními cestami a nepřetržitě prohledávat síť pomocí tradičních TCP/IP prohledávacích (sniffing) technik. Poté, co detekuje certifikáty doménového administrátora uvnitř sítě (například proto, že se administrátor se přihlašuje z blízké pracovní stanice), uloží si jeho uživatelské jméno a haš hesla.

Systémy založené na NT nepřenášejí heslo v čistém textu, ale nejdříve ho přepočítají pomocí jednosměrné hašovací funkce. Tato funkce nemůže být provedena opačným směrem, takže z haše se heslo přímo získat nedá. Červ však útokem hrubou výpočetní silou vyzkouší každou možnou kombinaci znaků. Každé takto získané heslo (A, AA, AAA, AAAA atd.) přepočítá stejnou jednosměrnou hašovací funkcí a porovná výsledek. Pokud se shodují, heslo bylo nalezeno. Podobným způsobem může červ použít slovníkovou metodu útoku na heslo.

V případě silného hesla tento proces může zabrat spoustu dní, ale typické NT heslo na obvyklé pracovní stanici vybavené procesorem Pentium bývá prolomeno za méně než týden. Za předpokladu, že červ může komunikovat s ostatními napadenými uzly a může si mezi ně rozložit výpočetní zátěž, dá se proces ještě více urychlit.

Poté, co červ získá heslo doménového administrátora, je síť prakticky jeho a může s ní dělat cokoliv, co se mu zamane. Typicky se nakopíruje na všechny stanice v síti. Na NT založených strojích se dokonce může spouštět automaticky s vyššími přístupovými právy. Červ může rovněž změnit heslo doménového administrátora a lokální administrátorská hesla, čímž znesnadní své odstranění.

Možnost útoku na NT domény jsme poprvé analyzovali v roce 1997 s Mikko Hypponenem. Zhruba v té době se objevily programy jako L0phtCrack, které se ujaly úkolu zachytávání paketů a lámání hesel z hašů systémů založenýcn na NT. Autoři programu L0phtCrack prakticky demonstrovali skutečnost, že dlouhá hesla bývají často slabší než kratší hesla v případě slovníkového útoku25.

Hašovací algoritmus v NT doménách navíc rozděluje dlouhá hesla na části po sedmi znacích, čímž programům typu L0phtCrack umožňuje získávat hesla ještě rychleji. Nicméně červi se zabudovaným odchytávačem packetů a schopností lámat hesla ještě nebyly nalezeny. Zabezpečte si svá hesla nyní – předtím než bude pozdě! (Tato rada samozřejmě nezní příliš fundovaně, zejména pokud uvážíme existenci počítačových červů se sledováním stisknutých kláves.)

9.3.3 Skenování sítě a označení cíle Postupem mnohých červů je vytváření náhodných IP adres za účelem útoku na další uzly sítě. Analýzou skenovacího algoritmu takového červa jsme schopni zhruba předpovídat, jakou rychlostí se bude skrze síť šířit.

Je jasné, že útočník může skenovat celý internet z jediného stroje a vytvářet IP adresu sekvenčním způsobem (jako např. 3.1.1.1, 3.1.1.2, 3.1.1.3 atd) a pečlivě ignorovat nefunkční rozmezí IP adres. Tato metoda dovoluje útočníkovi vybudovat seznam "obětí" (databázi IP adres) – seznam systémů s patrnou zranitelností proti různým typům útoku. Za tímto účelem si útočník "osahá" vzdálený systém natolik, aby mohl předpokládat, že je cíl zranitelný. V mnoha případech je tato metoda silně propojena s úspěšnou exploitací.

292

Kapitola 9 – Strategie počítačových červů

Metoda "obětí" je jeden z teoretických základů pro takzvané Warholovy červy26. Warholův červ je schopen infikovat 90% všech zranitelných systémů celého internetu za méně než 15 minut. (Předpokládá se, že budoucí přechod na IPv6 donutí červy přejít z tradičních skenovacích metod na metodu "obětí".)

9.3.3.1 Skenování za použití předdefinované tabulky tříd: červ Linux/Slapper Síťoví červi mohou skenovat vzdálené systémy generováním náhodných IP adres s tím, že použijí předdefinovanou tabulku síťových tříd. Například červ Linux/Slapper používá třídy uvedené ve výpisu 9.1 pro útoky na potenciálně zranitelné systémy Apache běžící na operačním systému Linux:

Výpis 9.1 Definice tříd červa Linux/Slapper. unsigned char classes[] = { 3, 4, 6, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 28, 29, 30, 32, 33, 34, 35, 38, 40, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 61, 62, 63, 64, 65, 66, 67, 68, 80, 81, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239 } ;

Poznámka Jméno pro červa Linux/Slapper jsem zvolil poté, co byl objeven v září 2002. Jméno bylo vybráno pro jeho podobnost s kódem červa BSD/Scalper. Červ Scalper útočil na systémy Apache se "scalp" kódem exploitu – a to byl hlavní důvod pro výběr tohoto jména pro tento virus.

Předcházející třídy neobsahovaly některé třídy velikosti A, lokální sítě (jako 10) nebo různé další rozsahy IP adres, včetně neplatných tříd. Rutina, podle které si červ vytváří databázi IP adres cílových strojů, je uvedena ve výpisu 9.2

Výpis 9.2 Rutina, pomocí které červ Linux/Slapper vytváří náhodnou IP adresu. a=classes[rand()%(sizeof classes)]; b=rand(); c=0; d=0;

Útok začne na adrese typu 199.8.0.0, přičemž červ začne skenovat celý rozsah síťového uzlu. Slapper se pokouší připojit k portu 80 (HTTP), aby si "osahal" vzdálený systém. Dělá to odesíláním předstíraného

Počítačové viry – analýza útoku a obrana

293

požadavku HTTP na port 80, který postrádá hlavičku Host: (tuto hlavičku protokol HTTP/1.1 vyžaduje). Předstíraný požadavek je uveden ve výpisu 9.3.

Výpis 9.3 Předstíraný HTTP požadavek červa Linux/Slapper.

GET / HTTP/1.1\ r\ n\ r\ n

Červ očekává, že webový server Apache, v reakci na tento požadavek, vrátí chybovou zprávu. Chybová zpráva, kterou Apache vrátí útočníkovi, je uvedena ve výpisu 9.4:

Výpis 9.4 Odpověď webového serveru Apache.

HTTP/1.1 400 Bad Request Date: Mon, 23 Feb 2004 23:43:42 GMT Apache Web Server’s Answer Server: Apache/1.3.19 (UNIX)

(Red-Hat Red-Hat/Linux) mod_ssl/2.8.1

OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01 Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1

Povšimněte si klíčových slov Server: Apache uvedených v chybové hlášce. Vrácená data dále obsahují informaci o aktuální verzi webového serveru, který je v tomto případě verze 1.3.19. Červ pomocí klíčového slova "server" zkontroluje, zdali chybová hláška pochází od serveru Apache.

Poté použije tabulku naplněnou údaji o architektuře a číslech verzí (viz výpis 9.5) a zjistí, zdali cíl patří mezi cíle vhodné pro útok.

Výpis 9.5 Tabulka s údaji o architektuře a číslech verzí v červu Slapper. struct archs { char *os; char *apache; int func_addr; }

architectures[] = { { "Gentoo", "", 0x08086c34} , { "Debian", "1.3.26", 0x080863cc}, { "Red-Hat", "1.3.6", 0x080707ec}, { "Red-Hat", "1.3.9", 0x0808ccc4}, { "Red-Hat", "1.3.12", 0x0808f614}, { "Red-Hat", "1.3.12", 0x0809251c}, { "Red-Hat", "1.3.19", 0x0809af8c},

Kapitola 9 – Strategie počítačových červů

294

{ "Red-Hat", "1.3.20", 0x080994d4}, { "Red-Hat", "1.3.26", 0x08161c14}, { "Red-Hat", "1.3.23", 0x0808528c}, { "Red-Hat", "1.3.22", 0x0808400c}, { "SuSE", "1.3.12", 0x0809f54c}, { "SuSE", "1.3.17", 0x08099984}, { "SuSE", "1.3.19", 0x08099ec8}, { "SuSE", "1.3.20", 0x08099da8}, { "SuSE", "1.3.23", 0x08086168}, { "SuSE", "1.3.23", 0x080861c8}, { "Mandrake", "1.3.14", 0x0809d6c4}, { "Mandrake", "1.3.19", 0x0809ea98}, { "Mandrake", "1.3.20", 0x0809e97c}, { "Mandrake", "1.3.23", 0x08086580}, { "Slackware", "1.3.26", 0x083d37fc}, { "Slackware", "1.3.26", 0x080b2100} } ;

Útočník v tuto chvíli ví, že na vzdáleném systému běží systém Apache, který je pravděpodobně vhodný k exploitaci používanou červen (předpokládáme, že systém doposud nebyl záplatován). Třetí hodnotou je "kouzelná" adresa spojená s exploitačním kódem. Toto kouzelné číslo je vysvětleno v desáté kapitole.

V našem případě si červ vybere adresu 0x0809af8c, protože se jedná o RedHat a verzi 1.3.19. (všimněte si zvýrazněných znaků v seznamu.)

9.3.3.2 Náhodné skenování: červ W32/Slammer Červ Slammer byl zatím nejrychleji se šířícím červem v historii. Slammer útočil na UDP port 1434 (což je SQL server) a ani se neobtěžoval ověřovat, zdali je daná IP adresa korektní. Jednoduše generoval náhodné IP adresy a každému takovému cíli posílal příslušné pakety (viz tabulka 9.2.)

Tabulka 9.2 – Náhodné skenování červa Slammer. Čas

IP adresa cíle:port

0.00049448

186.63.210.15:1434

0.00110433

73.224.212.240:1434

0.00167424

156.250.31.226:1434

0.00227515

163.183.53.80:1434

0.00575352

142.92.63.3:1434

0.00600663

205.217.177.104:1434

0.00617341

16.30.92.25:1434

Počítačové viry – analýza útoku a obrana

Čas

IP adresa cíle:port

0.00633991

71.29.72.14:1434

0.00650697

162.187.243.220:1434

0.00667403

145.12.18.226:1434

0.00689780

196.149.3.211:1434

0.00706486

43.134.57.196:1434

0.00723192

246.16.168.21:1434

0.00734088

149.92.155.30:1434

0.00750710

184.181.180.134:1434

0.00767332

79.246.126.21:1434

0.00783926

138.80.13.228:1434

0.00800521

217.237.10.87:1434

0.00817112

236.17.200.51:1434

295

Způsob, kterým Slammer útočí, se v budoucnu jeví jako nejrychlejší možný útok na internet, nicméně výzkumníci se domnívají, že některé typy červů se budou v budoucnosti šířit ještě rychleji. Infekce červem Slammer byla pozorována téměř současně po celém světě, červ ani nepotřeboval techniku "osahávání". Spoléhal se na "jistý zásah" do zranitelných cílů, díky nimž se infekce rozběhla do dalších uzlů.

9.3.3.3 Kombinace skenovacích metod: červ W32/Welchia Červ Welchia používá generátor IP adres podobným způsobem jako Slapper. K tomu však navíc používá následující kombinace metod: 

Welchia skenuje sítě třídy B s adresou, která je blízká adrese hostitele. Dělá to skenováním adresy, která je buď stejná, nebo je lehce nad, nebo lehce pod, v naději, že blízké systémy by mohly být také zranitelné stejným exploitem.



Červ dále používá techniku seznamu "obětí" pro sítě třídy A. Útočník předpokládá, že tyto systémy budou zranitelnějším cílem. Tato metoda navíc používá náhodnou strategii skenování a útočí na všech 65536 náhodných IP adres.

Předtím, než Welchia přistoupí k samotnému exploitu, zkontroluje, zda-li je cíl dosažitelný (pomocí ICMP požadavku echo).

9.4 Šíření infekce Tato sekce popisuje zajímavé způsoby, kterými se počítačoví červi šíří do nových systémů.

296

Kapitola 9 – Strategie počítačových červů

9.4.1 Útok na systémy kompromitované pomocí zadních vrátek Přestože většina počítačových červů schválně neútočí na již kompromitované systémy, někteří červi zaměrně používají cizí zadní vrátka pro své šíření. Červ W32/Borm červ byl jedním z prvních počítačových červů, který útočil na již kompromitované vzdálené cíle pomocí zadních dvířek. Byl ovšem schopen infikovat pouze systémy kompromitované pomocí Back Orifice (mezi útočníky poměrně populární zadní vrátka). Back Orifice podporuje rozhraní vzdáleného přístupu, které používá zakódované spojení mezi klientem a serverem Back Orifice nainstalovaném na kompromitovaném systému. Červ Borm používá metodu skenování sítě a "osahávání" za účelem vyhledání systémů s těmito zadnými vrátky.

Podrobněji je to zobrazeno na obrázku 9.5.

Obrázek 9.5

Červ W32/Borm ke svému šíření používá Back Orifice.

Červ útočí na systém pomocí následujících jednoduchých kroků: 1. Náhodně generuje IP adresu a aktivně ji skenuje za použití příkazu BO_PING programu Back Orifice, aby zjistil, zdali je vzdálený systém kompromitován. K inicializaci smysluplné komunikace červ musí použít heslo, které je *!*QWTY?. Hlavička komunikačních dat je zakódována pomocí jednoduché šifry, která je vyžadována serverem Back Orifice. Červ Borm data náležitě zakóduje předtím, než je odešle na náhodně vygenerovanou IP adresu, přičemž použije port 31337/UDP podporovaný serverem Back Orifice. Pokud vzdálený systém na příkaz BO_PING odpoví, červ přejde do dalšího kroku. V opačném případě vygeneruje další IP adresu.

2. Borm pošle serveru příkaz BO_HTTP_ENABLE.

Počítačové viry – analýza útoku a obrana

297

3. Tímto příkazem je server Back Orifice instruován k vytvoření virtuálního HTTP serveru na kompromitovaném hostitelském počítači. Červ bude poté (po Back Orifice), požadovat vytvoření HTTP proxy pomocí portu 12345/TCP. 4. Červ se připojí a nahraje sám sebe na server v kódovaném formátu MIME. 5. Nakonec červ spustí na vzdáleném počítači, pomocí příkazu BO_PROCESS_SPAWN, nahrané soubory. Na vzdáleném počítači se tak zprovozní nová kopie červa, která může začít z tohoto nově infikovaného uzlu hledat další systémy kompromitované pomocí Back Orifice.

W32/Borm byl jedním z řady počítačových červů, které se objevily v roce 2001. Další červ, který používal rozhraní zadních vrátek, byl červ Nimda, který využíval zadní vrátka vytvořená předchozí infekcí viru CodeRed II. A měl bych také zmínit červa W32/Leaves, který se dostal do oběhu díky útokům na systémy kompromitované trojským koněm SubSeven.

Borm byl výtvorem brazilského autora virů jménem Vecna. Některé další jeho metody budou popisovány později v této kapitole.

9.4.2 Útoky na peer-to-peer sítě Útoky na peer-to-peer sítě (P2P) mají výhodu v používání poměrně jednoduchých technik, protože se nevyžadují žádné složité skenovací metody – i to může být důvodem vzrůstající popularity tohoto typu útoků. Červ jednoduše vytvoří své kopie ve složce, která je sdílená v síti P2P. Všechno, co je v této složce, je pak k dispozici všem dalším uživatelům P2P sítě.

Někteří počítačoví červi dokonce vytvoří sdílenou složku i v případě, kdy uživatel využívá síť pouze ke stahování dat (tzn. nenabízí žádná data ke stažení). Přestože je tento útok pak dosti podobný spíše instalaci trojského koně, než rekurzivnímu šíření, uživatelé snadno najdou sdílený obsah a jeho spuštěním dokončí infekční cyklus. Mnozí P2P červi, jako například W32/Maax, infikují soubory ve složce, která je sdílena v P2P síti. Nejběžnější metodou infekce je jednoduché přepsání souborů, ale jsou k vidění i složitější techniky jako třeba prepender nebo dokonce appender.

Typičtí P2P klienti jako například KaZaA, KaZaA Lite, Limewire, Morpheus, Grokster, BearShare a Edonkey jsou běžným terčem škodlivého software. P2P sítě jsou v současnosti nejoblíbenějším způsobem výměny digitální hudby – jsou těžko regulovatelné a necentralizované.

9.4.3 Útoky pomocí systémů pro okamžitý přenos zpráv Útoky pomocí systémů pro okamžitý přenos zpráv (instant messaging) mají původ ve zneužívání příkazu DCC Send programu mIRC. Tento příkaz se dal využít pro odeslání souboru konkrétnímu uživateli připojenému k určitému diskusnímu kanálu. Útočník obvykle modifikoval lokální skriptovací soubor, například script.ini, který byl používán programem mIRC pro instruování klienta, aby poslal nějaký soubor pokaždé, když se do diskuse připojí nový účastník.

Moderní implementace IRC (Internet Relay Chat) červů se umí dynamicky připojovat k IRC klientům a posílat zprávy, které příjemce přesvědčí ke spuštění odkazu nebo přílohy. Takto se útočník může obejít bez modifikace lokálních souborů.

298

Kapitola 9 – Strategie počítačových červů

Napříkla, takový červ W32/Choke používá API programu MSN Messenger k rozesílání sebe sama dalším účastníkům, přičemž předstírá, že se jedná o "počítačovou střílečku"27. Přestože mnohé systémy pro okamžitou komunikaci (např. ICQ) vyžadují, aby uživatel stiskl tlačítko pro odeslání souboru, červi umí vytvořit příslušná dialogová okna a a potvrdit je, bez vědomí přítomného uživatele. Dá se také předpokládat, že počítačoví červi časem zneužijí v těchto programech zranitelností typu přetečení zásobníku. Například některé verze programu AOL Instant Messenger umožňují dálkové spuštění libovolného kódu skrze dlouhý parametr ve funkci pro získávání her28.

9.4.4 Útoky pomocí e-mailů a klamavých technik Velká většina počítačových červů se do jiných systémů šíří skrze e-mail. Je až překvapivé, jak se útočníci každodenně snaží oklamat příjemce, přičemž je žádají o spuštění neznámého kódu, který jim dorazil e-mailem. Přiznejme si, že toto je jeden z největších problémů v bezpečnosti. Jak mohou bezpečnostní experti chránit uživatele před nimi samotnými?

V průběhu posledních několika let se zvyšuje množství uživatelů lapených v "matrixu" operačních systémů (jako například Windows). Speciálně Windows dávají iluzi milionům počítačových uživatelů, že právě oni jsou pány svých počítačů a nikoliv jejich otroky. Tato iluze vede ke snížené opatrnosti. Je smutným faktem, že mnoho uživatelů vůbec netuší, že musí být opatrní při práci s přílohami e-mailů.

Například takový červ W97M/Melissa použil k oklamání (a také k přesvědčení příjemců ke spuštění červa) e-mail následujícího znění: "Here is that document you asked for ... don’t show anyone else ;-)" "Tady je ten dokument, o který sis říkal … neukazuj ho nikomu jinému ;-)" Další běžnou klamavou metodou je zfalšování záhlaví e-mailu. Útočník může například uvést jako adresu odesílatele e-mail support@microsoft.com (tak to třeba dělá virus W32/Parvo). To může snadno přesvědčit uživatele, že e-mail je důvěryhodný, přičemž následně bez přemýšlení otevřou přílohu e-mailu. Jiné počítačové viry, jako třeba W32/Hyd, čekají tak dlouho, dokud nějaký uživatel nedostane e-mail, přičemž původnímu odesílateli pošlou okamžitě "odpověď", s červem v příloze. Není vůbec překvapivé, že se jedná o mimorádně účinnou metodu. Červi také dělají drobné změny v políčku Od:, aby změnili e-mail odesílatele v něco nepravého. V praxi tak můžete dostat e-mailové zprávy od mnoha lidí, kteří nemají vůbec nic společného s červem, který pouze zneužil jejich adresu. Následné upozornění "odesílatele" tedy nemusí mít žádný význam.

9.4.5 Útoky pomocí přímého vkládání e-mailů do schránky Někteří počítačoví červi vkládají zprávy přímo do e-mailových schránek. Tímto způsobem červ vůbec nemusí posílat zprávy – jednoduše se totiž spolehne na to, že e-mailový klient zprávu otevře. Nejstarší typy počítačových červů na systémech Windows byly právě tohoto typu. Příkladem toho je třeba červ Win/Redteam, který útočí na odchozí e-mailové schránky e-mailového klienta Eudora.

Počítačové viry – analýza útoku a obrana

299

9.4.6 Útoky založené na SMTP Proxy W32/Taripox@mm29 je příkladem lstivého červa, který se chová jako SMTP proxy. Tento červ se objevil v únoru 2002. Taripox útočí na soubor %WINDOWS %\SYSTEM32\DRIVERS\ETC\HOSTS, aby přesměroval veškerý e-mailový provoz na sebe. Soubor HOSTS používá velmi jednoduchou definici pro adresu vedoucí na localhost (viz výpis 9.6).

Výpis 9.6 Typický obsah konfiguračního souboru hostitele.

127.0.0.1

localhost

W32/Taripox tuto IP adresu SMTP serveru pro localhost přemapuje. Červ pak může poslouchat na portu 25 (SMTP), přičemž čeká, až se pokusí připojit nějaký e-mailový klient používající SMTP. Odchozí e-mailová zpráva je sice poslána na skutečný SMTP server, ale ještě předtím je email infikován přílohou zakódovanou pomocí MIME. Červ dále v hostitelských souborech mate uživatele pomocí komentářů typu "# Leave this untouched" (toto nechte na pokoji), který je používán pro položku localhost nebo pomocí textu "# do not remove!" (neodstraňovat!), který je použit ke komentáři k IP adrese SMTP položky s přemapovanou adresou localhost. Obrázek 9.6 ilustruje fungováni tohoto červa.

Obrázek 9.6

Použití SMTP proxy červem W32/Taripox .

Soubor HOSTS je obvyklým cílem pro retro červy, kteří tak mohou zakázat přístup k webovým stránkám různých antivirových a bezpečnostních společností. Taripoxův útok je podobný útoku červa Happy99, ale je mnohem jednodušší a nevyžaduje komplikované změny v binárních souborech, jako třeba v souboru WSOCK32.DLL.

9.4.7 Útoky přes SMTP Poté, co Microsoft zvýšil bezpečnost Outlooku, aby lépe ochránil koncové uživatele před útoky červů, začali autoři červů ve větší míře používat útoky založené na SMTP.

Kapitola 9 – Strategie počítačových červů

300

První takový celosvětový průlom byl způsoben červem Sircam20 v červenci 2001 a byl následován nechvalně proslulým červem W32/Nimda v září 2001. Menší průlomy naznačovaly budoucí problémy již dříve, například výskyt červa W32/ExploreZip v červnu 1999.

Sircam se vyhnul obvyklému zvyku se spoléhat na e-mailový program a získával SMTP informace přímo z registrů. Tyto informace se skládají z následujících klíčů, které byly vytvořeny a jsou používány velkým počtem e-mailových aplikací společnosti Microsoft: 

E-mailová adresa současného uživatele – HKCU\Software\Microsoft\Internet Account Manager\Default Mail Account\Accounts\SMTP Email Address.



Adresa e-mailového serveru – HKCU\Software\Microsoft\Internet Account Manager\Default Mail Account\Accounts\SMTP Server.



Zobrazované jméno uživatele – HKCU\Software\Microsoft\Internet Account Manager\Default Mail Account\Accounts\SMTP Display Name.

Pokud z nejrůznějších důvodů tyto informace neexistují, Sircam použije e-mailový server prodigy. net.mx, přičemž použije přihlašovací jméno uživatele pro vytvoření e-mailové adresy a pro zobrazování jména. Napevno zakódovaný seznam IP adres SMTP serverů je u červů běžnou technikou, bohužel poté, co se červ dostatečně rozšíří, se tyto servery velmi snadno přetíží, protože nezvládnou zpracovat takové velké množství požadavků.

Díky různým omylům v implementaci a chybám nějakou dobu trvalo, než se SMTP červi dostatečně rozšířili. Před červem Sircam totiž většina červů postrádala nějaký důležitý detail ve svém mechanismu šíření. Například takový Magistr18 často posílal prázdné soubory nebo soubory, které – ačkoliv byly infikovány – vyžadovaly pro své spuštění knihovny, které počítač příjemce většinou neobsahoval, takže infekce cílového systému se vůbec nekonala atd.

Typická SMTP komunikace mezi serverem a klientem vypadá takto: 1. Klient se připojuje k serveru 2. Server posílá 220 3. HELO jmeno.cz – pozdrav serveru 4. Server posílá 250 5. MAIL FROM: <jmeno odesilatele> 6. Server posílá 250 7. RCPT TO: <jmeno prijemce> 8. Server posílá 250 9. DATA 10. Server posílá 354 11. Tělo e-mailu Předmět: <jakýkoliv předmět> (následuje zakódovaná příloha)

Počítačové viry – analýza útoku a obrana

301

. – tečka pro ukončení 12. Server posílá 250 13. QUIT – loučíme se se serverem 14. Server posílá 221 V tuto chvíli může být e-mail vložen do složky s dočasným jménem na serveru v EML (Electronic Mail List, seznam elektronických adres). Například obrázek 9.7 ukazuje e-mailovou zprávu poslanou červem W32/Aliz, která je uložena v e-mailové složce programu IIS Server od Microsoftu.

Obrázek 9.7

E-mailová zpráva červa W32/Aliz.

Tato vybraná část kódu v obrázku odkrývá exploit Content-Type v těle e-mailu, to bude detailněji probráno v kapitole 10. Další zajímavé části kódu různých virů je možné najít v kapitole 15, která se věnuje analýze technik škodlivého kódu.

9.4.8 Použití MX dotazů pro zrychlené šíření pomocí SMTP Červi jako Nimda, Klez, Sobig a Mydoom zdokonalili techniku automatizovaného rozesílání přes SMTP rozpoznáváním adres SMTP serverů použitím MX (eMail eXchanger) záznamů v DNS (Domain Name System). Tito červi zkontrolují doménové jméno e-mailové adresy, kterou zachytili, čímž získají korektní SMTP server pro tuto doménu. Červ Mydoom dokonce využíval místo primárních adres SMTP serverů adresy sekundární, aby tak snížil budoucí zátěž SMTP serverů.

Tabulka 9.4 obsahuje seznam vyhledávání MX záznamů červa Mydoom na pokusném systému. Červ se okamžitě rozesílá na systémy, které je schopen korektně najít a dělá to několikrát za minutu. První sloupec tabulky ukazuje čas v sekundách, druhý sloupec je IP adresa infikovaného systému a čtvrtý sloupec ukazuje IP adresu DNS serveru použitou pro vyhledání MX záznamů.

302

Kapitola 9 – Strategie počítačových červů

Tabulka 9.4 – DNS dotazy červa Mydoom. Čas

IP stanice

IP DNS

Typ dotazu

Dotazovaná hodnota

5.201889

192.168.0.1

->

192.168.0.3

standardní DNS dotaz

MX dclf.npl.co.uk

5.450294

192.168.0.1

->

192.168.0.3

standardní DNS dotaz

MX frec.bull.fr

6.651133

192.168.0.1

->

192.168.0.3

standardní DNS dotaz

MX csc.liv.ac.uk

18.036855

192.168.0.1

->

192.168.0.3

standardní DNS dotaz

MX esrf.fr

19.721399

192.168.0.1

->

192.168.0.3

standardní DNS dotaz

MX welcom.gen.nz

30.761329

192.168.0.1

->

192.168.0.3

standardní DNS dotaz

MX t-online.de

32.213049

192.168.0.1

->

192.168.0.3

standardní DNS dotaz

MX welcom.gen.nz

32.447161

192.168.0.1

->

192.168.0.3

standardní DNS dotaz

MX geocities.com

9.4.9 Útoky pomocí NNTP (Network News Transfer Protocol) Červi jako Happy99 se mohou šířit skrze newsgroupy stejně dobře jako skrze e-mailové adresy. Útoky na USENETy mohou dále rozšířit možnosti šíření počítačových červů. Je tedy až s podivem, že většina počítačových červů se šíří pouze přes e-mailové adresy.

9.5 Běžný kód červa a spouštěcí techniky Počítačoví červi se také liší v tom, jak šíří svůj kód z jednoho počítače na druhý. Většina počítačových červů se jednoduše šíří jako příloha e-mailu. Jiní červi používají k útoku na další systém nejrůznější metody, jako třeba injektáž kódu nebo techniky shellkódu ve spojení s exploitačním kódem.

9.5.1 Útoky založené na spustitelném kódu E-mail může být zakódován mnoha způsoby – například pomocí UU, BASE64 (MIME) a mnoha dalšími. Přesto však nejsou přílohy zakódované pomocí UU příliš spolehlivé, neboť obsahují různé znaky, jejichž interpretace je závislá na kontextu. V dnešní době většina e-mailových klientů standardně používá kódování příloh MIME – a to je ten hlavní způsob, pomocí kterého se většina počítačových červů šíří skrze klienty SMTP na nové cíle. Skriptovací e-mailoví červi obvykle používají přílohy, které jsou zakódované podle nastavení e-mailového klienta na kompromitované straně.

9.5.2 Odkazy na webové stránky nebo webové proxy Počítačoví červi také mohou posílat odkazy na spustitelné soubory, které mohou být fyzicky umístěny úplně kdekoliv – ať už na jednotlivé webové stránce, mnoha webových stránkách nebo na FTP serveru.

Nejnovější zpráva na IRC nebo v e-mailu nemusí obsahovat přímo škodlivý obsah – infekce nicméně může proběhnout nepřímo. Problém tohoto způsobu útoku je potenciální možnost náhodného DoS útoku proti systému, který fyzicky hostuje kód červa. Další možné úskalí je to, že se obránce může

Počítačové viry – analýza útoku a obrana

303

snadno obrátit na poskytovatele hostingu a následně si vyžádat znepřístupnění dané stránky a tím tak zabránit dalšímu šíření červa.

Rafinovaní červi rovnou posílají IP adresu už kompromitovaného systému. Probíhá to tak, že červ nejprve kompromituje nějaký stroj a rozběhne na něm webový server. Poté odesílá zprávy dalším uživatelům a používá přitom IP adresu stroje a port, kde už červ netrpělivě čeká na příkaz GET. V takovém případě se z červa stává síť typu peer-to-peer, jak to ilustruje obrázek 9.8. Podobní červi jsou přitom schopni obejít případné filtrování obsahu (pokud je filtrovací pravidlo založeno na filtrování přílohy).

Obrázek 9.8

Rafinovaní červi posílají odkazy v e-mailech místo svých kopií.

W32/Beagle.T používal podobnou metodu v březnu 2004. Tato varianta Beagle otevřela jednoduchý webový server na TCP portu 81. Poté odeslala příjemcům, pomocí e-mailu založeného na HTML, odkaz, který spustil automatické stahování spustitelných souborů červa (bylo to možné s využitím slabiny "object tag" v prohlížeči Internet Explorer od Microsoftu, která byla popsána v bulletinu MS03-032). Po stažení se pak tyto soubory automaticky vykonaly. Červ W32/Aplore jako jeden z prvních použil tento typ útoku na systémech pro okamžitý přenos zpráv (instant messaging) v dubnu 2002. Poté, co se červ W32/Aplore@mm30 dostal do nového systému, choval se jako jednoduchý webový server a pomocí portu 8180 zpřístupnil webovou stránku, navádějící uživatele ke stažení a spuštění programu, kterým bylo samotné tělo červa. Červ se snažil oklamat uživatele těchto komunikačních programů odesláním odkazu, který vypadal takto: FREE PORN: http://free:porn@192.168.0.1:8180

Použitá IP adresa samozřejmě odpovídala adrese infikovaného systému :-).

9.5.3 E-mail založený na HTML kódu V e-mailu je možné používat některé vlastnosti jazyka HTML. Pokud chcete snížit šanci na úspěšné napadení systému nějakým červem (např. VBS/Bubbleboy), zrušte ve svém e-mailovém programu zob-

304

Kapitola 9 – Strategie počítačových červů

razování zpráv ve formátu HTML. Takové emaily pak budou zobrazovány jako textové. Zmiňovaný červ je dále popisován v kapitole 10.

9.5.4 Útoky založené na vzdáleném přihlašování Na systémech UNIX mohou červi přímo používat příkazy jako rsh, rlogin, rcp a rexec. Pokud tyto systémy nejsou zabezpečeny, nebo pokud se podaří kompromitovat heslo pomocí slovníkového útoku nebo útoku hrubou silou, mohou se červi s využitím těchto příkazů spouštět na vzdálených systémech. Červ obvykle na vzdáleném systému vytvoří svoji kopii a spustí se.

Na systémech Windows využívají červi jako JS/Spida slabin v serverech Microsoft SQL. Spida vyhledává na portu 1433 vzdálené systémy se serverem Microsoft SQL a pokouší se o vzdálené spuštění sebe sama, za následujících předpokladů: 

Microsoft SQL server běží v administrátorském módu.



Účet "sa" nemá na Microsoft SQL serveru nastavené heslo.

Červ využívá funkci xp_cmdshell, pomocí které může používat vzdálené příkazy ke svému spuštění.

9.5.5 Útoky injektáží kódu Pokročilejším způsobem útoku je přímá injektáž kódu do vzdáleného počítače pomocí sítě. Pomalu končí doba tradičních metod založených na přetečení zásobníku a útočníky začínají stále více zajímat metody zaměřující se na využití slabin na straně serveru, které jsou spojeny s nedostatkem kontroly vstupních dat. Například červ Perl/Santy používá Google pro vyhledávání zranitelných webových stránek se systémem phpBB, kde následně spouští vlastní skript v jazyce Perl. Červ byl v prosinci 2004 úspěšný v napadení tisíců webových stránek. V závislosti na způsobu používání threadů tohoto zranitelného softwaru pak akce červa pokračovala takto: 

Po spuštění serveru je založeno nový thread.



Při každém příchozím požadavku je založeno nový thread.

Dále v závislosti na kontextu "ukradnutého" (hijacked) threadu se červ: 

Rozběhne s vysokými právy v kontextu SYSTEM.



Rozběhne v kontextu uživatele s vysokými nebo nízkými právy, takže nákaza může eskalovat.

Když například červ W32/Slammer objeví zranitelný Microsoft SQL server, červ ukradne thread, který byl spuštěn při startu tohoto serveru. Takže operace spojené s tímto ukradeným threadem budou paralyzovány, protože nové požadavky nebudou vyřizovány. Navíc je server, a vlastně, úplně celý systém přetížený, protože se červ nikdy nepřestane odesílat na další cíle.

Ukázkou druhého typu útoku je W32/CodeRed. CodeRed proniká na servery Microsoft IIS pomocí upraveného požadavku GET. Poté, co server dostane požadavek GET, spustí nový thread, aby jej mohl vyřídit. Červ tento thread ukradne a vytvoří na zranitelném serveru dalších 100 (v některých variantách 300) threadů. Pro tento typ počítačového červa je důležité, aby neinfikoval stejný systém dvakrát, protože by to mohlo způsobit rychlé přetížení serveru krátce po rozšíření červa.

Počítačové viry – analýza útoku a obrana

305

Oba útoky jsou z pohledu exploitace detailně popsány v kapitole 10. Zřetelně to ukazuje obrázek 9.9.

Obrázek 9.9

Typický jednosměrný útok pomocí injektáže kódu.

V některých případech vytváří injektovaný kód na cílovém počítači nového uživatele, takže útočník má možnost vzdáleného připojení se k systému.

Dalším příkladem útoku pomocí injektáže kódu je červ W32/Lespaul@mm. Tento červ využívá zranitelnosti programu Eudora 5, která může být použita pro průnik pomocí upraveného příznaku pole.

Lespaul je červ masově rozesílající e-maily, ale podobně jako CodeRed nebo Slammer, injektuje svůj kód přímo do zranitelného procesu Eudory 5. Červ příjemci neposílá žádnou přílohu, místo toho se šíří přímo v těle e-mailu. V e-mailové schránce programu Eudora pak vypadá jako část e-mailové zprávy, která obsahuje neobvykle velké pole hlavičky. Vlastní kód není nikdy uložen jako samostatně spustitelný soubor.

9.5.6 Útoky založené na interpretech příkazů Další třídou počítačových červů jsou ti, kteří používají interpret příkazů na vzdáleném stroji. Základní myšlenkou je na vzdáleném počítači spustit pomocí eploitace příkazovou řádku, jako například cmd.exe (na systémech Windows) nebo /bin/sh (on UNIX). Pro ilustraci si prohlédněte obrázek 9.10

Obrázek 9.10

Typický útok založený na interpretu příkazů.

Červ provádí následující kroky: 1. Injektuje kód do vzdáleného procesu a propojí specifický port s tímto procesem. Tento proces pak začne naslouchat na tomto portu.

2. Červ se začne pokoušet připojit k naslouchajícímu portu.

306

Kapitola 9 – Strategie počítačových červů

3. Jestliže bude připojení úspěšné, již dříve infikovaný interpret příkazů spustí příkazovou řádku a propojí proces se stejným portem, jako používá útočník.

4. Červ může posílat příkazy interpretu.

Ukázkou takového červa je W32/Blaster. Útoky založené na interpretech příkazů jsou mnohem častější na systémech UNIX než na systémech Windows. Existuje několik variant, jako například zpětně se připojující kód interpretu, který opět použije již existující připojení.

Zpětně se připojující kód interpretu se okamžitě pokusí propojit útočníka s cílem vytvořením TCP připojení ke stroji útočníka. Výhodou tohoto typu útoku je, že umožňuje i napadení systémů s firewallem.

Tento typ útoku vyžaduje, aby systém útočníka naslouchal na určitém portu a čekal, až se připojí kód interpretu, jak je znázorněno na obrázku 9.11.

Obrázek 9.11

Zpětně se připojující kód interpretu.

Hlavní rozdíl nastává v druhém kroku. Kód interpretu se spustí na cílovém počítači a připojí se k útočníkovi. Po ukončení spojení kód interpretu spustí příkazovou řádku, která již přijímá příkazy od útočníka. Tento přístup například používá červ W32/Welchia. Exploitace může být provedena v několika krocích. Například, červ Linux/Slapper exploituje cíl mnohonásobným útokem – kód interpretu se pak spustí díky přetečení heapu. Slapper však implementuje i další techniky založené na interpretu, třeba tak, že opětovně použije spojení vytvořené mezi počítačem útočníka a cílem útoku. Jak je patrné z obrázku 9.12, kód interpretu se tak nepotřebuje znovu připojovat k cíli útoku. V kapitole 15 můžete vidět kód interpretu červa Slapper, pomocí kterého je opětovné použití spojení názornější.

Obrázek 9.12

Kód interpretu, který opětovně používá již vytvořené spojení.

Počítačové viry – analýza útoku a obrana

307

9.6 Aktualizační strategie počítačových červů Počítačoví červi mohou být rozděleni do tříd podle své schopnosti se aktualizovat. Ranou ukázkou tohoto fenoménu je W95/Babylonia, který infikuje soubory nápovědy systému Windows a soubory PE. Červ byl objeven v prosinci 1999. Červ Babylonia byl odeslán do internetové newsgroups alt.crackers jako soubor nápovědy k systému Windows. Soubor byl pojmenován jako serialz.hlp31, čímž se tvářil jako seznam sériových čísel komerčních programů. Tento soubor si spustilo velké množství uživatelů, čímž tak na svých počítačích aktivovali virus. Ten po svém spuštění vytvoří komponentu, pomocí které vyhledává dostupné aktualizace na webové stránce. (Jak to ilustruje obrázek 9.13.)

Stahovač (downloader) viru jako první přečte obsah textového souboru pojmenovaného virus.txt, který je uložen na webové stránce. Tento soubor obsahuje několik názvů souborů, jako například dropper. dat, greetz.dat, ircworm.dat a poll.dat. Tyto soubory používají speciální formát plug-inu se záhlavím, který začíná identifikátorem VMOD (což je slovo vytvořené z výrazu virus module). Záhlaví plug-inu obsahuje ukazatel na další plug-in, přičemž stahovací součást viru Babylonia postupně stáhne a spustí všechny plug-iny, jeden za druhým.

Obrázek 9.13

Aktualizační procedura viru Babylonia.



Modul dropper.dat umí znovu nainstalovat kód viru na počítač. Tímto může autor viru zaměnit stávající verzi viru za novou nebo dokonce opětovně infikovat již vyčištěný systém.



Modul greetz.dat je payloadem. Modifikuje soubor c:\autoexec.bat a zobrazuje každý den v lednu zprávu uvedenou ve výpisu 9.7.



Modul ircworm.dat je instalátor, pomocí kterého červ infikuje další cíle s využitím mIRC.



Modul poll.dat je používán ke zjištění počtu napadených strojů. Po spuštění se odešle e-mail na adresu babylonia_counter@hotmail.com s portugalskou zprávou "Quando o mestre chegara?"

(Kdy pán dorazí?).

308

Kapitola 9 – Strategie počítačových červů

Výpis 9.7 Payload červa Babylonia.

W95/Babylonia by Vecna (c) 1999 Greetz to RoadKil and VirusBuster Big thankz to sok4ever webmaster Abracos pra galera brazuca!!!

--Eu boto fogo na Babilonia!

Virus Babylonia je nejenom schopen infikovat dva odlišné souborové formáty Windows, ale současně napadá i soubor WSOCK32.DLL, což mu umožňuje odesílat e-maily s přílohami kdykoliv, když uživatel odesílá své vlastní e-maily. Babylonia si tuto myšlenku vypůjčila od červa Happy99.

Slabinou tohoto útoku je aktualizační systém založený na jediné webové stránce. Poté, co byla tato stránky odstraněna, Babylonia již nebyla schopna stahovat žádné nové komponenty.

9.6.1 Autentizované aktualizace z webu Jako reakci na slabinu aktualizačního systému založeném na jediné stránce, se Vecna rozhodl použít alternativní aktualizační kanály a navíc přidal silné šifrování pro autentizaci těchto aktualizací. Finální výtvor, červ W95/Hybris, byl zveřejněn na konci roku 2000. Jednalo se o nezvykle velký projekt několika špičkových tvůrců virů z celého světa – na vytvoření viru se podíleli autoři z Brazílie, Španělska, Ruska a Francie.

Hybris používá 1023 bitový RSA podpis32 pro doručení aktualizačních modulů do infikovaných systémů. Je použita 128bitová hašovací funkce pro ochranu aktualizace před případným útokem. Tato hašovací funkce používá XTEA (rozšířený kódovací algoritmus, který je následníkem algoritmu TEA).

XTEA je programem typu public domain, vytvořený Davidem Wheelerem a Rogerem Needhamem.

RSA knihovna byla pro tento virus vytvořena proslulým ruským autorem virů jménem Zombie. Obrázek 9.14 ilustruje způsob útoku viru Hybris.

Počítačové viry – analýza útoku a obrana

Obrázek 9.14

309

Autentizační model aktualizace červa Hybris.

Povšimněte si zajímavého výběru algoritmu XTEA místo TEA, který byl na konferenci CRYPTO 1996 označen kryptografy Johnem Kelseyem, Brucem Schneierem a Davidem Wagnerem jako příliš slabý. Je zajímavou informací, že algoritmus TEA byl použit pro hašovací funkci zajišťující bezpečnost v druhé verzi produktu Xbox společnosti Microsoft. O této zranitelnosti se začalo diskutovat ihned den poté, co byla zveřejněna nová specifikace Xboxu, přičemž tým vedený Andym Greenem prolomil bezpečnostní schéma Xboxu přehozením několika bitů kódu FLASH ROM, což umožnilo volný přístup do paměti RAM33.

Myšlenkou červa Hybris bylo zašifrovat aktualizace pomocí algoritmu XTEA a podepisovat tyto soubory pomocí RSA na útočníkově systému. Probíhalo to tak, že útočník vytvořil tajný klíč a k němu odpovídající veřejný klíč. Veřejný klíč se vložil do viru, přičemž kódovací a dekódovací klíče XTEA byly doručeny společně modulemm, a jsou podepsány pomocí tajného, 1023bitového, RSA klíče. Tento postup se nazývá jako hybridní technika podpisu a výrazně zefektivňuje celý proces.

Namísto použití jednoho 128bitového klíče Hybris používá 8 klíčů XTEA, přičemž každý první z nich je vypočítán pomocí haše, přičemž 7 zbývajících 128bitových klíčů je nastaveno náhodně. Nejdříve je pomocí XTEA vypočítán 128bitový haš. Tato hodnota je jako jedna z osmi použita k zakódování celého modulu za použití 64bitové blokové šifry XTEA. Bloková šifra se aplikuje na všech osm 128bitových klíčů (včetně haše plug-inu), které jsou určeny pro každý 64bitový blok plug-inu. Každý 64bitový blok je zakódován jedním 128bitovým klíčem. Takže – první 64bitový blok je zakódován prvním klíčem, druhý 64bitový blok je zakódován druhým 128bitovým klíčem, dokud se nedojde na konec. Devátý blok je pak opět zakódován prvním klíčem atd.

310

Kapitola 9 – Strategie počítačových červů

Toto podepisování umožňuje červovi zkontrolovat, zdali aktualizační soubory pocházejí od autora viru.

Tímto je algoritmus RSA použit k ochraně plug-inu před neoprávněnými změnami od třetích stran nebo k vytvoření nového plug-inu útočníkem, který vlastní tajný klíč. Červ používá veřejný klíč, který odpovídá tajnému klíči útočníka, pro potvrzení platnosti podepsaného klíče XTEA, přičemž se ověřuje, zdali je haš správný. Pokud ano, pak se nejedná o útok podvrženým plug-inem.

Přestože jsou aktualizace zašifrovány, jedná se o algoritmus používající symetrický klíč, takže moduly mohou být dekódovány podobným způsobem jako je dekóduje samotný červ. Útočník je však chráněn proti manipulacím, které by měly za cíl úpravu modulů. Tím pádem není možné distribuovat aktualizaci, která by bez znalosti tajného klíče donutila červa k autodestrukci, samozřejmě, pokud nedojde k objevu nějaké chyby v implementaci, jak se v případě kryptografie často stává.

Pro Hybris vzniklo na dvacet známých modulů (nazývaní jako Muazzini), nicméně v oběhu bylo více než 32 různých verzí. Po zašifrování a podepsání modulu jej útočník zakódoval a odeslal do newsgroup alt.comp.virus. Infikované systémy, které na tyto moduly čekaly, si je nahrály a dekódovaly prostřednictvím svých veřejných klíčů.

Přestože původní aktualizační webová stránka byla velmi rychle odstraněna, útočníci měli možnost zasílat nové aktualizace prostřednictvím newsgroups. Infikované uzly pak posílaly moduly zpátky do těchto newsgroups, takže všechny infikované uzly měly možnost se dostat k aktualizacím.

Hybris také používal techniku podobající se algoritmu červa Happy99 pro vložení svého kódu do knihovny WSOCK32.DLL, což mu umožňovalo šířit se e-mailem.

Aktualizační moduly pro červa byly tyto následující: 

Modul napadající EXE soubory systému DOS.



Modul určený pro infekci PE souborů takovým způsobem, aby se nezměnila ani jejich velikost, ani kontrolní součet CRC 16/32/48. Tento modul používal kompresi pro zkomprimování hostitele a zaplnění modulu dalšími daty, za použití algoritmu ruského autora virů jménem Zhengxi, pomocí kterého bylo možno dosáhnout stejného kontrolního součtu jako před infekcí.



Modul pro zakódování souboru WSOCK32.DLL infikovaného Hybrisem.



Modul pro infekci souborů nápovědy Windows. (´Kód byl vypůjčen z červa W95/Babylonia.)



Modul pro infekci používající polymorfní funkce KME autora Zombie.



Dva moduly umožňující infekci uvnitř archivů RAR, ZIP a ARJ.



Dva rozdílné moduly pro infekci dokumentů programu Microsoft Word a další pro infekci dokumentů Microsoft Excelu.



Modul pro DoS útoky.



Zakódovaný generátor trojských koňů.



Modul umožňující infekci pomocí zadních vrátek viru SubSeven.



Modul zpráv HATE (human-alike text engine). Tento modul je schopen generovat e-mailové zprávy se jmény známých antivirových výzkumníků, jako je například Eugene Kaspersky, Mikko Hypponen nebo Vesselin Bontchev. Mé jméno bylo rovněž v seznamu. Tento modul byl vytvo-

Počítačové viry – analýza útoku a obrana

311

řen k odesílání e-mailových zpráv za použití jedné z adres v poli odesílatele, s předmětem typu "Uglier than Hermann Monster!" (pravděpodobně odkaz na Hermana Munstera) s přílohou pojmenovanou jako "The Hungarian Freak!.exe".

Poznámka Tento modul vytvořil španělský autor virů Mr. Sandman, zakladatel skupina 29A, sdružující autory virů. Předpokládá se, že se jedná o profesionálního překladatele. Některé další viry tohoto autora jsou totiž spojeny s jeho zájmem o jazyky, například Esperanto a Haiku.



Útočný retro modul, bránící v přístupu ke stránkám s antiviry.



Generátor e-mailových zpráv, který za použití webového serveru SOAP generuje přáníčkové zprávy a tyto pak odesílá příjemcům (i s virem Hybris).



Aplikace infikující soubory SYS za účelem ukrytí infikovaného WSOCK32.DLL pomocí stealth rutin.



Exploitační modul určený k získávání souborů ze zranitelných webových serverů.



Modul určený k prohledávání harddisku a registrů, nalezení antivirových programů a jejich následné smazání, včetně zničení databází.



E-mailově založený modul trackeru posílající zprávy z infikovaných uzlů na určité adresy.



Několik dalších generátorů zpráv určených pro šíření e-maily.



Modul Happy 2000. Tento přepisuje soubor SKA.EXE červa Happy99 a místo něj šíří Hybris.

Obsahuje rovněž grafický payload červa Happy99.



Modul pro stahování dodatečných plug-inů z webových stránek.



Usenetový modul pro připojování se k serverům NNTP a stahování plug-inů. Tento modul také uploaduje jiné moduly do newsgroups.



Animace založená na OpenGL, která se nainstaluje při bootování. Tento modul, zobrazený na obrázku 9.15, je příspěvkem francouzského autora virů jménem Spanska.

312

Obrázek 9.15

Kapitola 9 – Strategie počítačových červů

Plug-in obsahující hypnotizérskou spirálu založenou na OpenGL.

Výpis 9.8 ukazuje plug-in modul vystavený v newsgroup alt.comp.virus34.

Výpis 9.8 Aktualizace viru Hybris na alt.comp.virus (vybraná část kódu).

Date: Tue, 24 Jul 2001 20:29:51 -0700 Newsgroups: alt.comp.virus Subject: h_2k MRKR KRnAbIvQdE?UlOhK6CrWdU#YvYnM:SrYU TRUTUWXXPTVFVY3NXSTREYCUSPVNBLZLSQBPXXRRYMUOD7USWESFRWYBUTREMBLWKSPS OXYVNWZG KTVHVDMTTRODVSMCZFWCQXSXVVTZVUKVKHOBTRNFYVVBLFRBXWUVRHWHPF SE&THUFNVMHZCRHNVRVZUKXVWSBSBZRPB6NEVVYZLSVSLDLZZFZCYCSWKDLUZVYR5ZYLZ NDOSNUKRMUYXOHTEMUKD

Tělo zprávy obsahuje plug-in Happy 2000pro Hybrise (ve výpisu 9.8 je uvedena pouze vybraná část kódu). Jméno plug-inu (h_2k) je uvedeno v předmětu e-mailu a je následováno číslem verze. Hybris tuto informaci používá k rozhodování, zdali tento modul potřebuje.

9.6.2 Aktualizace založené na zadních vrátkách Mnozí počítačoví červi otevřou na kompromitovaném počítači nějaký port a následně zprovozní rozhraní, pomocí kterého mohou na takovém počítači spustit libovolné soubory. Útočník může toto rozhraní použít třeba pro aktualizaci těla červa na novou verzi. Například červ 32/Mydoom otevře TCP port v rozmezí 3127 až 3198 a čeká na spojení, které se uskuteční pomocí jednoduchého protokolu.

V případě aktualizace červa Mydoom se jedná o techniku šíření pomocí zadních vrátek, popisovanou

Počítačové viry – analýza útoku a obrana

313

dříve v této kapitole. Útočník hledá systém, který má otevřený port a pokud takový najde, pošle tam soubor, který se na vzdáleném systému spustí. Prvních několik verzí červa neobsahovalo žádný zabezpečovací mechanismus v aktualizačním protokolu. Není proto překvapením, že různí červové jako W32/Doomjuice, W32/Beagle nebo W32/Welchia útočily na systémy kompromitované červem Mydoom a získávaly tak výhodu díky nezabezpečenému mechanismu aktualizací.

Pozdější verze červa Mydoom kontrolovaly příchozí požadavky už mnohem obezřetněji.

9.7 Vzdálené ovládání pomocí signalizace Útočníci velmi rádi ovládají své výtvory na dálku, například ke spuštění DoS útoku proti vybranému cíli nebo ke kontrole šíření červa na další systémy. Nejpoužívanější technika je ta, která je založená na zadních vrátkách, pomocí kterých červ komunikuje přímo s hostitelem. Rozhodně však není jediná, existují totiž další techniky založené na ovládání prostřednictvím IRC nebo doménových e-mailových slotů Windows. Prohlédněte si obrázek 9.16, který ilustruje způsob útoku červa W32/Tendoolf.

Obrázek 9.16

Vzdáleně ovládaný červ Tendoolf.

Některé varianty tohoto červa se šíří až poté, co útočník zašle červovi pomocí IRC kanálu signál ".spread". Po odeslání tohoto signálu začne kompromitovaný systém vyhledávat nové oběti. Jeho technikami šíření je e-mail, instant messaging (ICQ) a zadní vrátka viru SubSeven. A jako bonus může útočník spustit DoS útok proti libovolnému cíli. Cíl DoS útoku není na kompromitovaném systému znám až do doby, než útočník spustí příkaz (červ ho totiž nemá zakódovaný natvrdo). Poté se kompromitovaný uzel obrátí na specifikovaný cíl a spustí několik technik, pomocí kterých server zahltí. Od této činnosti pochází i pravé jméno červa, které zní Floodnet (čteno pozpátku).

314

Kapitola 9 – Strategie počítačových červů

Šíření červů pomocí vzdáleného ovládání je pro začínající antivirové výzkumníky matoucí.

9.7.1 Kontrola nad Peer-to-Peer sítěmi Někteří počítačoví červi vytvářejí mezi jednotlivými infikovanými uzly virtuální síť, pomocí které mohou komunikovat a ovládat probíhající operace. Červ Linux/Slapper je typickou ukázkou takového červa. Slapper na každém infikovaném uzlu používá protokol UDP a port 2002. Poté, co červ infikuje nový uzel, pošle útočníkovi IP adresu tohoto systému. Poté je tato adresa rozeslána všem uzlům a uložena v seznamu. Kdykoliv se objeví nová adresa, všechny uzly ji dostanou pomocí speciální virtuální sítě, která používá některé schopnosti TCP pro ujištění, že informace dorazila všem v pořádku. Infikovaný uzel pak zvolí náhodnou skupinu jiných strojů pro vyslání aktualizovaných informací. Tomuto říkáme segmentová vysílací technika (broadcast segmentation technique).

Rozhraní dálkového ovládání červa Linux/Slapper je velmi pokročilé. Kód je vypůjčen od červa BSD/ Scalper. Slapper od Scalpera rovněž implementuje podobnou hierarchickou síťovou strukturu35, která zachovává informace o napadených strojích. Slapper podporuje velké množství příkazů včetně UDP zaplavení (UDP flood), TCP SYN zaplavení (TCP SYN flood), IPv6 SYN zaplavení (IPv6 SYN food) atd.

Na kompromitovaných systémech rovněž podporuje spouštění rozličných příkazů.

Obrázek 9.17 zobrazuje obvyklý postup infekce červem Slapper. Poté, co je infikován první uzel, získá IP adresu útočícího hostitele následovanou seznamem uzlů, které už jsou připojeny do sítě.

Obrázek 9.17

Infekce červem Slapper.

Obrázek 9.17 pouze ilustruje, jak se infekce přesunuje z jednoho systému do druhého. Obrázek 9.18 ukazuje možné vysvětlení hierarchických vztahů mezi infikovanými uzly uspořádanými ve stylu P2P

Počítačové viry – analýza útoku a obrana

315

sítě. Protože útočník může začít infekci na více místech najednou, mohou existovat menší nebo větší paralelní P2P sítě, které nemají přímé spojení s ostatními, jak je to vidět na obrázku 9.18.

Obrázek 9.18

Síťová hierarchie P2P červa Slapper.

9.8 Úmyslné a náhodné interakce Antiviroví výzkumníci měli možnost sledovat několik zajímavých způsobů interakcí mezi různými druhy škodlivého kódu, některé náhodné, jiné úmyslné. Tato sekce popíše typické způsoby interakcí.

9.8.1 Spolupráce Některé počítačové viry spolupracují s jiným virovým kódem zcela náhodně. Například, počítačový červ může být při průchodu síťovými uzly napaden nějakým infektorem souborů. V praxi jsou běžné několikanásobné infekce počítačovými červy. Není neobvyklé najít tři nebo více různých virů rozšiřovaných jedním počítačovým červem. Tato situace může různými způsoby pomoci jak červovi, tak i klasickým virovým infektorům. Červ může profitovat z infekce neznámým virem. Pokud je pro antivirové produkty tento virus neznámý, může se vyhnout detekci i tělo červa. V některých případech je červ schován hluboko v kódu viru – tím snižuje možnost antivirového programu ho nalézt. Tuto situaci ilustruje obrázek 9.19.

316

Obrázek 9.19

Kapitola 9 – Strategie počítačových červů

Náhodná interakce mezi červem a virem.

V kroku A je počítač infikován červem. V kroku B červ napadá nový systém. Tento počítač je však již napaden virem, který infikoval právě ty soubory, které pro své šíření používá i červ. Červ se tak připojí k souboru s virem. V kroku C už na další počítač proniká mnohonásobná infekce. Po spuštění červa je spuštěn i virus (ve většině případů se rozběhne ještě před kódem červa) a infikuje další objekty.

V kroku D dorazí kombinace viru a červa na systém vybavený antivirovým programem, který sice dokáže najít virus v těle červa, ale nedokáže už najít červa samotného. Pokud antivir umí soubor vyléčit, je možné, že vytvoří soubor, který nebude zcela shodný s původním červem. Binární část může být zvětšena nebo zmenšena a dokonce může dojít i ke změnám v hlavičce. (Je jasné, že antivir je pouze jeden z mnoha programů, které mohou pozměnit kód škodlivých programů.)

Takto vzniklý "zmutovaný" červ má šanci se šířit dále a napadnout systém v kroku E. Žádný antivir v praxi nebude schopen tohoto upraveného červa považovat za variantu původního počítačového červa.

Antiviry každopádně musí tento problém řešit. Kontrolní součet MD5 "zmutovaného" těla červa je zcela odlišný a pokud antivir nebo nějaký jiný program pro kontrolu obsahu používá pro detekci červa pouze tuto metodu, pak v tomto případě při detekci jednoznačně neuspěje.

Zvláštním případem takové spolupráce může být symbióza, která se vyskytla v projektu autora jménem GriYo. Publikoval hromadně se rozesílajícího e-mailového červa W32/Cholera, který byl infikován polymorfním virem W32/CTX. Výsledkem byl rychlý úspěch obou, jak W32/Cholera, tak i W32/CTX, po celém světě. Výsledkem toho bylo, že W32/CTX byl ohlášen na Wildlistu.

Viry infikující soubory, jako například W32/Funlove, často infikují ostatní červy a to ve spoustě případů i mnohonásobně. Takový virus postupně zmizí z tabulky top 50, aby se tam náhle vrátil po vypuknutí epidemie určitého počítačového červa. Toto bylo zjevné zejména v případě červa W32/Beagle. Jak už bylo zmíněno dříve, Beagle posílá příjemcům zaheslované přílohy. Protože červ vytváří soubor archivu

Počítačové viry – analýza útoku a obrana

317

(ZIP) na lokálním počítači, spustitelný soubor červa může být jednoduše napaden virem typu Funlove ještě předtím, než je zabalen. Takže viry typu Funlove se mohou "těšit" z ochrany heslem36. A protože mnohé antivirové systémy mají s detekcí zaheslovaných příloh problémy, mohou viry, které "cestují" tímto způsobem, získat díky náhodné spolupráci s červem nezanedbatelnou výhodu.

Určitou formou spolupráce bylo také červem W32/Borm už zmiňované využití počítačů, které byly kompromitovány programem Back Orifice. Červ W32/Borm se nepokusí Back Orifice odstranit, pouze jej využije ke svému šíření. A již dříve zmiňovaný Mydoom rovněž obsahoval zadní vrátka, která pro své šíření využíval červ Doomjuice.

S makroviry a viry ve skriptech mají souvislost útoky nazvané jako "krádeže těl" (body snatching). Dva nebo více skriptů může vytvořit nový škodlivý produkt tak, že náhodným způsobem šíří svůj kód společně.

9.8.2 Soutěžení Soutěživost taky občas patří mezi možné způsoby interakcí mezi počítačovými viry. Různé viry útočí na jiné a čistí kompromitované systémy. Příkladem je bootovací virus Den_Zuko37, který odstraňuje virus Brain. Tyto viry se často nazývají jako "užitečné" nebo jako "antivirové".

Počítačoví červi útočící na jiné byly zpopularizovány v roce 2001 – po objevení červa CodeRed a na něj útočícího červa CodeGreen. Takové "užitečné" červy bylo ovšem možné spatřit už předtím, typicky na Linuxu.

Protože nějaká zranitelnost IIS může být zneužita mnohonásobně, CodeGreen může snadno útočit na uzly napadené červem CodeRed. Červ posílá vzdálenému cíli požadavek GET, který je podobný požadavek GET červa CodeRed. Požadavek GET červa CodeGreen je uveden ve výpisu 9.9.

Výpis 9.9 Požadavek GET červa CodeGreen.

GET /default.ida?Code_Green_<I_like_the_colour-_-><AntiCodeRedCodeRedIII-IDQ_Patcher>_V1.0_beta_written_by_’Der_HexXer’Wuerzburg_Germany-_is_dedicated_to_my_sisterli_’Doro’.

Save_Whale_and_visit_<www.buhaboard.de>_and_www.buha-security.de

Červ v sobě dále nese zprávu uvedenou ve výpisu 9.10.

Výpis 9.10 Zprávy červa CodeGreen.

HexXer’s CodeGreen V1.0 beta CodeGreen has entered your system it tried to patch your system and to remove CodeRedII’s backdoors You may uninstall the patch via SystemPanel/Sofware: Windows 2000 Hotfix [Q300972]

318

Kapitola 9 – Strategie počítačových červů

get details at "www.microsoft.com". visit "www.buha-security.de

CodeGreen zlikviduje infekci červa CodeRed a zároveň odstraní zadní vrátka, která byla důležitou komponentou některých verzí červa CodeRed. A dále pak stáhnul a nainstaloval záplaty, které odstranily zranitelnost v systému. Podobné útoky bylo také možné pozorovat v době, kdy červ W32/Welchia začal svůj boj proti červu W32/Blaster, čímž zahájil tzv. "válku červů".

Dalším fascinujícím příkladem je červ W32/Sasser. Ten útočil na slabé místo LSASS, které bylo již v minulosti exploitováno různými variantami červa Gaobot. Tvůrce červa Gaobot tím určitě nebyl příliš nadšen, protože jeho červ Gaobot tak musel s červem Sasser bojovat o volné cíle. Zřejmě z toho důvodu byla nová varianta červa W32/Gaobot.AJS38 vytvořena s "upíří" technikou útoku. Rozhodl jsem se tuto techniku pojmenovat podle upířího útoku v Core War, kde mohli Vampíři krást duše svým nepřátelům (detaily viz kapitola 1).

Gaobot.AJS je upírem – pokud jsou náhodou na systému přítomni oba červi, zaútočí na Sassera. Ovšem namísto triviálního smazání rafinovaně pozmění jeho kód. Výsledkem této modifikace je to, že Sasser může stále vyhledávat nové cíle a dokonce je může i úspěšně exploitovat. Ale když se pak Sasser připojí ke svému shell-kódu na kompromitovaném systému, aby jej navedl ke stažení a spuštění kopie Sassera z FTP, převezme kontrolu modifikovaná část kódu. V tomto okamžiku červ Gaobot.AJS odešle Sasserovu shell-kódu na vzdáleném počítači příkaz ke stažení a spuštění kopie červa. Ale nikoliv ke stažení a spuštění červa Sasser, ale červa Gaobot.AJS. Červ Gaobot následně ukončí spojení, takže se Sasser nemůže šířit a je de facto použit pouze pro šíření červa Gaobot, který se zde chová jako nefalšovaný parazit.

Dalším zajímavým případem je červ W32/Dabber, který se objevil krátce po objevení červa Sasser. Již jsme říkali, že shell-kód červa Sasser je instruován ke stažení své kopie z FTP. Toto jednoduché FTP je provozováno na systému útočníka. Naneštěstí – tato rutina má jednoduše exploitovatelnou zranitelnost spočívající v přetečení zásobníku. (Takže i červi mohou mít vlastní zranitelnosti!) Červ Dabber byl vytvořen tak, že využije tuto zranitelnost červa Sasser ve prospěch vlastního šíření. Dabber tedy vyhledává cíle kompromitované červem Sasser a pokouší se připojit k zranitelnému FTP serveru tohoto červa.

V budoucnu se dá očekávat častější výskyt soutěživosti mezi jednotlivými škodlivými programy.

9.8.3 Budoucnost – jednoduchý komunikační protokol pro červy?

Protože je zvýšení soutěživosti mezi škodlivými programy velmi pravděpodobné, mohou útočníci investovat trochu svého času do vývoje různých spolupracujících technik. Například – různé druhy počítačových červů by mohly používat jednotný speciální komunikační protokol pro vzájemnou výměnu informací nebo dokonce plug-inů. Jednotliví počítačoví červi by si tak mohli vyměňovat payloady, informace o možných cílích nebo dokonce sbírat e-mailové adresy a sdílet je s ostatními červy používajících tento protokol. Jsem přesvědčen, že podobné techniky se objeví už v blízké budoucnosti.

Je nepochybné, že tato komunikace by měla mít různé formy. Například viry by se mohly reprodukovat "sexuálně"39, křížit svůj genofond a vytvářet potomky, kteří by se mohli dále vyvíjet (popř. upadat).

Počítačové viry – analýza útoku a obrana

319

Náhodnou "sexuální" reprodukci můžeme u počítačových virů najít už dnes – u makrovirů, kteří si občas prohodí, resp. půjčí svá makra (geny), jak je to probíráno v kapitole 3. Navíc, speciálně naprogramované binární viry by eventuálně mohly vykazovat podobné chování, které by vedlo k vytvoření dalších nových virů.

9.9 Červi pro bezdrátová mobilní zařízení Červ SymbOS/Cabir40 je předzvěstí zcela nové éry počítačových červů, která se časem jistě rozvine, podobně jako se rozvíjí popularita chytrých bezdrátových telefonů, které postupně nahrazují běžné mobilní telefony s omezenými schopnostmi. Červ Cabir se objevil v červnu 2004 a měl celou řadu unikátních vlastností. Tento červ funguje na telefonech Nokia série 60 s operačním systémem Symbian. Operační systém Symbian je založen na systému EPOC. Je faktem, že Symbian je ve skutečnosti EPOC verze 6, (také nazývaný jako EPOC 32), nicméně alespoň jméno systému je nové. Zajímavý je způsob šíření, jímž je v případě červa Cabir funkce Bluetooth na některých mobilních telefonech (viz obrázek 9.20).

Obrázek 9.20

Útočící telefon je vlevo, příjemce napravo.

Kód červa je kompatibilní s mobilními telefony používajícími procesor typu ARM a používající operační systém Symbian. Na telefonech je obvykle funkce komunikace pomocí Bluetooth (BT) vypnuta.

Uživatelé mobilních telefonů si mohou pomocí BT nahrávat různé programy, takže při jeho zapnutí otevřou možnou cestu různým červům jako je Cabir.

Po spuštění se červ Cabir nainstaluje do různých adresářů systému Symbian ve snaze zajistit si, že bude spuštěn po každém restartu zařízení. Naštěstí tato operace není na novějších typech telefonů. Na starších telefonech nemohou být komponenty červa nalezeny pomocí běžných souborových manažerů.

Cabir neprohledává všechna dostupná zařízení v Bluetooth, místo toho se pokouší komunikovat vždy s prvním zařízením v seznamu. Maximální vzdálenost, na které Bluetooth funguje, je zhruba 10 metrů, přičemž ne všechna dostupná zařízení s Bluetooth jsou ochotna spolu komunikovat. Výzkumníci jako

320

Kapitola 9 – Strategie počítačových červů

Mark Rowe jsou zkušení v technologii zesilování signálu Bluetooth a předpokládají, že útočníci by mohli použít podobnou technologii k útokům přesahujícím hranici 100 metrů. Další výzkumník jako Ollie Whitehouse z @stake prakticky demonstroval, že zařízení Bluetooth se dají nalézt i dokonce v "neviditelném" módu41. V současnosti již existuje několik útočných programů založených na BT, včetně těch nejpopulárnějších – Bluesniff, Btscanner, PSMscan, a Redfang.

V průběhu infekčních testů se červ Cabir nejprve pokusil komunikovat s tiskárnou podporující technologii Bluetooth printer, která se chovala jako návnada (honeypot) a zablokovala červa nevědomky tím, že nepodporuje protokol Object Exchange (OBEX), který je nutný k přenosu souborů. Poté, co jsme tuto tiskárnu vypnuli, červ úspěšně infikoval první mobilní telefon, který byl v dosahu. Červ Cabir je ovšem příliš aktivní ve vyhledávání dalších telefonů a snadno tak vybije baterii mobilního telefonu. Je to situace podobná té, kdy se váš telefon snaží najít síť mobilního operátora, aniž by byla nějaká dosahu.

Dalším problémem je to, že potřebujete být se svým telefonem "ukrytí", pokud testujete replikaci červa.

Přestože příjemce musí příchozí zprávu potvrdit, nechcete "náhodně" infikovat další telefon. Jsou totiž známy určité zranitelnosti systémů Bluetooth, přičemž některé z nich mohou být použity ke spuštění libovolného kódu na zařízeních typu Pocket PC42, zatímco další mohou být implementovány k phishing útokům na široké spektrum chytrých mobilních telefonů43.

V budoucnu můžeme dozajista očekávat červy používajících vaše telefony k telefonování bez vašeho vědomí. Také můžeme očekávat novou éru červů, kteří budou masově rozesílat skodlivé MMS nebo SMS zprávy. Kdo poté zaplatí účty?

Odkazy 1. Dr. Vesselin Bontchev, osobní komunikace, 2004.

2. Nick FitzGerald, "When Love Came to Town", Virus Bulletin, červen 2000, str. 6-7.

3. Donn Seeley, "A Tour of the worm", USENIX Conference, 1989, str. 287-304.

4. Frederic Perriot a Peter Szor, "An Analysis of the Slapper worm Exploit", Symantec Security Response, White Paper, Duben 2003, www.sarc.com/avcenter/whitepapers.html.

5. "The Cheese worm", CERT Incident Note IN-2001-05, http://www.cert.org/incident_ notes/IN-2001-05.html.

6. "The sadmind/IIS worm", CERT Advisory CA-2001-11, http://www.cert.org/advisory/ CA-2001-11.html.

7. Alexsander Czarnowski, "Distributed DoS Attacks – Is the AV Industry Ready?" Virus Bulletin Conference, 2000, str. 133-142.

8. Ido Dubrawsky, "Effects of worms on Internet Routing Stability", Security Focus, červen 2003, http://www.securityfocus.com/infocus/1702.

9. Frederic Perriot, "Crack Addict", Virus Bulletin, prosinec 2002, str. 6-7, http://www.virusbtn.com/resources/viry/indepth/opaserv.xml.

10. National Bureau of Standards, "Data Encryption Standard", FIPS Publication 46, U.S. Department of Commerce, 1977.

Počítačové viry – analýza útoku a obrana

321

11. Electronic Frontier Foundation, "Cracking DES", Sebastopol, CA, 1998, ISBN: 1-56592-520-3.

12. Dr. Steve R. White, "Covert Distributed Processing with Computer Viruses", Advances in Cryptology – CRYPTO ’89, Springer-Verlag, 1990, str. 616-619.

13. Dr. Vesselin Bontchev, "Anatomy of a Virus Epidemic", Virus Bulletin Conference, 2001, str. 389406.

14. Eugene H. Spafford, "The Internet worm Program: An Analysis", 1988.

15. Katrin Tocheva, "Worming the Internet – Part 2", Virus Bulletin,listopad 2001, str. 12-13.

16. Peter Ferrie, "Sleep-Inducing", Virus Bulletin, duben 2003, str. 5-6.

17. Katrin Tocheva, Mikko Hypponen a Sami Rautiainen, "Melissa", březen 1999, http://www.f-secure.com/v-descs/melissa.shtml.

18. Peter Ferrie, "Magisterium Abraxas", Virus Bulletin, květen 2001, str. 6-7.

19. Gabor Szappanos a Tibor Marticsek, "Patriot Games", Virus Bulletin, červenec 2004, str. 6-9.

20. Peter Ferrie a Peter Szor, "Sircamstantial Evidence", Virus Bulletin, září 2001, str. 8-10.

21. Dmitry O. Gryaznov, "Virus Patrol: Five Years of Scanning the Usenet", Virus Bulletin Conference 2002, str. 195-198.

22. Peter Szor, "Parvo – One Sick Puppy?" Virus Bulletin, leden 1999, str. 7-9.

23. Atli Gudmundsson and Andre Post, "W32.Toal.A@mm", http://securityresponse.symantec.com/avcenter/venc/data/w32.toal.a@mm.html.

24. Peter Szor, "Happy Gets Lucky?" Virus Bulletin, duben 1999, str. 6-7.

25. Stuart McClure, Joel Scambray a George Kurtz, "Hacking Exposed: Network Security Secrets and Solutions", 3. vydání, Osborn/McGraw-Hill, Berkeley, 2001, ISBN: 0-07-219381-6.

26. Vern Paxson, Stuart Staniford a Nicholas Weaver, "How to 0wn the Internet in Your Spare Time", http://www.icir.org/vern/papers/cdc-usenix-sec02/.

27. Neal Hindocha a Eric Chien, "Malicious Threats and Vulnerabilities in Instant Messaging", Symantec Security Response, White Paper, říjen 2003, www.sarc.com/avcenter/whitepapers. html.

28. "Buffer Overflow in AOL Instant Messenger", http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0005.

29. Sergei Shevchenko, "W32.Taripox.A@mm", únor 2002, http://securityresponse.symantec.com/avcenter/venc/data/w32.taripox@mm.html.

30. Katrin Tocheva a Erdelyi Gergely, "Aplore", duben 2002, http://www.f-secure.com/v-descs/aplore.shtml.

31. Marious van Oers, "Digital Rivers of Babylonia", Virus Bulletin, Únor 2000, str. 6-7.

32. Ronald L. Rivest, Adi Shamir a Leonard Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, v-21, n-2, únor 1978, str. 120-126.

322

Kapitola 9 – Strategie počítačových červů

33. Andrew "bunnie" Huang, "Hacking the Xbox", Xenatera LLX, San Francisco, 2003, ISBN: 159327-029-1.

34. Nick Fitzgerald, osobní komunikace, 2001.

35. Sen Hittel, "Modap OpenSSL červ Analysis", Security Focus, září 16, 2002.

36. Dr. Igor Muttik, osobní komunikace, 2004.

37. Dr. Vesselin Bontchev, "Are ‘Good’ Computer Viruses Still a Bad Idea?" EICAR, 1994, str. 25-47.

38. Heather Shannon, Symantec Security Response, osobní komunikace, 2004.

39. Edward Fredkin, "On the Soul", 2000, Draft Paper, http://www.digitalphilosophy.org/ on_the_soul.htm.

40. Peter Ferrie a Peter Szor, "Cabirn Fever", Virus Bulletin, srpen 2004, str. 4-5, http://pferrie. tripod.com/vb/cabir.pdf.

41. Ollie Whitehouse, "Redfang: The Bluetooth Device Hunter", 2003.

42. "WIDCOMM Bluetooth Communication Software Multiple Buffer Overflow Vulnerabilities", http://www.securityfocus.com/bin/10914/discussion.

43. "Bluetooth Information Disclosure Vulnerability", http://www.securityfocus.com/bin/ 9024/discussion.