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/Ostseespk_Rostock, miközben ez a szerver a DVG-nél, Hannoverben található. Egy támadás itt egy kicsit melegnek tűnt, mert például Hannoverben majdnem minden takarékpénztárat É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 szerveren nem ellenőrizték, mert egy végzetes rés a IIS-en, amely a parancsok dekódolását érintette, tökéletesen elegendő volt.
1.3.4 Hogyan védik a szervert? Úgy tűnt, a szervert tűzfal védi, mert nem válaszolt a pingekre, és kapcsolatokat sem engedett meg
kifelé. A szkennelések során nem derült ki pontosan, milyen tűzfalról volt szó, és azt sem lehetett megmondani, hogy a webszolgáltatón (80. port) és a HTTPS-en (443. port) kívül más portok elérése is megengedett-e, de ezt kizárni sem lehetett, mert a netstat-jelentés 4:00 óra körül kapcsolatokat mutatott a 4966/4967 portra. Mivel a távoli számítógépet egy komputernévvel jelölték, intranet kapcsolatból indulhattak ki. Íme a netstat-jelentés: Prot. Helyi címek
Távoli címek
Állapot
TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP
0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0
LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING
TC P TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP
Prot. TCP
0.0.0.0:135 0.0.0.0:135 0.0.0.0:161 0.0.0.0:512 0.0.0.0:1027 0.0.0.0:1031 0.0.0.0:1037 0.0.0.0:2867 0.0.0.0:2874 0.0.0.0:2882 0.0.0.0:3037 0.0.0.0:3038 0.0.0.0:3111 0.0.0.0:3125 0.0.0.0:3128 0.0.0.0:3168 0.0.0.0:3489 0.0.0.0:3697 0.0.0.0:4487 0.0.0.0:4796 0.0.0.0:5044 127.0.0.1:1025 127.0.0.1:1025 127.0.0.1:1026 127.0.0.1:1028 127.0.0.1:1031 1 72.24. 152.xx: 137 172.24. 152.xx:138 1 72.24. 152.xx: 139 1 72.24. 152.xx: 1029 172.24.1 52. xx:3038 1 72.24. 152.xx:31 11 172.24. 152. xx:3125 172.24.152.xx:3126 172.24.152.xx:3127 193.158.209.xx:80 193.158.209.xx:80 193.1 58. 209.xx:80 193.158.209.xx:80 193.158.209.xx:80 193.158.209.xx:80 193.1 58. 209.xx:80 193.158.209.xx:80 193.158.209.xx:80 193.158.209.xx:80 193.158.209.xx:137 193.158.209.xx:138 193.158.209.xx:139 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193. 158.209. xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443
0.0.0.0:0 127.0.0.1:1031 0.0.0.0:0 0.0.0.0:0 127.0.0.1:1025 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 172.24.153.4:80 172.24.153.4:80 172.24.153.5:1435 172.24.153.5:1435 172.24.153.5:1435 0.0.0.0:0 62.27.xx6.3:1036 62.46.166,211:4232 62.46.166.211:4233 62.xx6. 133.236:57480 193.101.4.4:1557 212.197.145.191:1042 212.197.157.61:1119 212.197.158.144:1073 217.2.206.133:4233 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 62.27.130.213:1182 62.27.130.213:1233 62.27.130.213:1234 62.27.130.213:1235 62.27.130.213:1236 62.27.130.213:1237 62.27.130.213:1238
LISTENING LISTENING ESTABLISHED LISTENING LISTENING ESTABLISHED LISTENING LISTENING LISTENING LISTENING ESTABLISHED TIME_WAIT ESTABLISHED TIME_WAIT TIME_WAIT LISTENING TIME_WAIT TIME_WAIT ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED LISTENING LISTENING LISTENING LISTENING CLOSING TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT
Helyi címek
Távoli címek
Állapot
193.158.209.xx:443
62.27.130.213:1240
TIME_WAIT
TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP UDP
193.1 58. 209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.1 58. 209.xx:443 193.158.209.xx:443 193.1 58.209. xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.1 58.209. xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.158.209.xx:443 193.1 58. 209.xx:443 1 93.1 58. 209.xx: 1030 193.158.209.xx:3128 0.0.0.0:135
62.27.130.213:1241 62.27.130.213:1242 62.27.130.213:1243 62.27.130.213:1244 62.27.130.213:1245 62.27.130.213:1246 62.27.130.213:1247 62.27.xx6.3:1037 62.27.xx6.3:1038 62.27.xx6.3:1039 62.27.xx6.3:1040 62.27.xx6.3:1041 62.27.xx6.3:1042 62.27.xx6.3:1043 62.27.xx6.3:1044 62.54.56.xx: 11 94 62.153.19.xx:1182 62.153.19.xx:1184 62.153.19.xx:1185 62.153.19.xx:1186 62.xx6.165.xx:2326 63.11.56. xx:1277 193.158. 209.xx:3121 193.158.209.xx:3128 209. 154.59.xx: 1202 0.0.0.0:0 193.158.209.xx:443 *:*
UDP
0.0.0.0:161
*:*
DP
172.24. 152.xx:137
*:*
UDP
172.24.152.xx:138
*:*
UDP
1 72.24. 152.xx: 1029
*:*
UDP
193.158.209.xx:137
*:*
UDP
193.24.152.xx:138
*:*
UDP
193.24.152.xx:1030
*:*
TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT ESTABLISHED CLOSING TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT TIME_WAIT CLOSING TIME_WAIT ESTABLISHED CLOSING LISTENING ESTABLISHED
1.3.5 Nincsenek logfájlok ezt biztosan az OFX irányítja IIS logfájlokat egyáltalán nem találtak, sem a C:\WINNT\ system32\LogFiles könyvtárban, sem máshol. Találtak viszont OFX-szoftver-jelentéseket, amelyek azonban nem adtak információt a kapcsolatokról. Feltételezték, hogy vagy a tűzfal log-okat értékelik ki, vagy teljesen lemondanak a loggolásról! Az OFX-ről A szerveren sem folyószámla-adatokat, sem adatbázis-jelszavakat vagy hasonlókat nem találtak. Ebből továbbra is arra következtettek, hogy ezeket központilag tárolják egy számítógépen, és ezt éri el, illetve kezeli az OFX szoftver. Az OFX-et az ASP-oldalakról - amelyek szokatlan módon nem VB scripteket, hanem JAVA scripteket használnak - vezérlik, és az adatokat nem lokálisan ellenőrzik; a felhasználói adatokat egy adatbázisba küldik, és ott hasonlítják össze. Tehát a tranzakcióknál a tranzakciók számai, a PIN és a felhasználó által megadott TAN az OFX-hez továbbítódik, amely aztán visszaadja a hibakódokat.
1.3.6 Adatátadás scriptekkel A szkennelés után világos lett, milyen módon lehetne megtámadni a szervert. Természetesen pontosan megnézték, hogyan is fogadja és továbbítja a rendszer az adatokat bejelentkezéskor. Előkészületek (hozzáférés megszerzése) A megfelelő URL megadásával elérték a hozzáférést. A parancsfordító CMD.EXE-t a webszerver rendszerkönyvtárából a script-könyvtárba másolták, hogy működőképesen legyen kezelhető a
böngészőből. Azonosítás és kapcsolat A weboldalakhoz vezető útvonal így nézett ki: C:\Inetpub\Root\Bank. Ebben a könyvtárban volt egy alkönyvtár, amelybe csak egy kódolt kapcsolattal lehet bejutni. Ebben a könyvtárban volt azoknak a fájloknak a nagy része, amelyeket az online banki szolgáltatás használ. Az ügyfeleket felkérik, hogy gépeljék be 6- vagy 10-jegyű online számukat, PIN kódjukat, és a kívánt bankot (a •••-t vagy a •••-t). Ezeket az adatokat aztán egy Session Cookie-ban (kódolt, az SSL miatt) tárolja a rendszer. A szerver támadhatóságának tesztelése A webszerver egy fatálisán szabványos exploitra volt érzékeny: http://www....de/scripts/..%c255winnt/system32/cmd.exe Itt egy hibáról volt szó egy átadott parancs dekódolásánál és legitimációjánál, ami végrehajtáshoz vezet. Megjegyzés: az adminisztrátor ezt a könyvtárat könyörtelelnül törölhette volna, mivel a bank scriptjei nem hajtanak végre bináris fájlokat, illetve nincs szükségük ilyenekre. Az IIS „sípolta" a konzolfájlok kiadását, például a CMD.EXE-t, ezért egyfajta shellt kaptak a böngészőn keresztül, ha a CMD.EXE-t a /c paraméterrel (egyedüli parancs) futtatták. Tiltott kimenő kapcsolatok Az első terv az volt, hogy egyszerűen féltőkének egy trójait, ami azután kényelmes olvasási és írási elérést kínálna. Ez azonban meghiúsult azon, hogy tiltva voltak a kimenő kapcsolatok. Tehát engedélyezett kapcsolatból kellett olvasni és írni. Az olvasási elérés nem volt probléma: az olvasandó fájlokat a webkönyvtárba másolták, letöltötték, majd törölték. A bökkenő az írás volt. Alapvetően az echo DOS-paranccsal lehet fájlokba írni. A szövegkarakterekkel nem is volt gond, viszont bináris adatokat és metakaraktereket, mint pl.: <, l ,> nem lehetett írni. A támadási tervről Bináris fájlokat ASP-scripttel írnak, illetve töltenek fel. Az ASP-scriptet, amely szövegkarakterekből áll, meg lehet írni a CMD.EXE-vel. Mivel azonban az ASP-hez és a HTML-hez is metakarakterek szükségesek, és a sorok „komplex" módon épülnek fel, ezeket nem lehetett a böngészőn keresztül bevinni, mivel a sornak URL kódoltnak kellett lennie, a sok nem alfanumerikus karakter miatt, és ezért a legrosszabb esetben háromszor olyan nagy lehetett volna. A sorokat tehát cookie-ként küldték el. Az adatok, mint például a HTTP_AGENT vagy a Remote-IP minden kérdésnél, környezeti változóként tárolódnak, és ezzel felhasználhatók más alkalmazások számára is, amelyeknek a webszerver a környezete. A cookie-t mint HTTP_COOKIE-t tárolták, és ezután az echo+%HTTP_COOKIE% -val egyszerűen lehetett írni. Az utolsó és legnagyobb dobás az volt, hogy a metakaraktereket idézőjelekbe csomagolva a szintakszisnak megfelelően írták (az ASP-scripthez). Amint a feltöltő-script a szerveren volt, át lehetett írni a bejelentkező-scriptet úgy, hogy a bejelentkező adatok a felhasználói űrlapról közvetlenül egy logfájlba vándoroljanak.
1.3.7 Az adatletöltés A megváltoztatott scriptek a C:\Temp\ 000043FA.ini könyvtárban tárolják a bank ügyfeleinek folyószámlaszámát, PIN-jét és IP-jét. Hogy ezt a fájlt le lehessen tölteni, ahhoz először a webkönyvtárba kellett másolni, majd egy hiperhivat-kozáson keresztül lehetett letölteni. Végül a fájlt törölni kellett, hogy ez a folyamat ne legyen olyan könnyen felfedezhető. Figyelembe kellett venni, hogy az első lépés már el volt intézve, és ezért itt már nem kellett foglalkozni vele!
A Bank.dat képernyője
A logfájlokból kapott adatokkal most már be lehetett jelentkezni az ügyfelek folyószámlájára.
Egy folyószámla képernyője
Egy részvény-portfólió képernyője
S még arra is nyílt lehetőség, hogy egy pillantást vessenek az ügyfelek részvényletétjére.
1.4 Utóirat a bank-hackeléshez A logfájlok áthúzása 2001.08.04-től 2001. 08.31-ig folyt. Ebben az időben több mint 1,5 millió adatot (online számokat, pineket, IP-címeket) mentettek le. Az adatokat végül az NDR jogi osztályának adták át, ahol bezárták egy széfbe ezeket. A •• bank a Hamburgi Területi Bíróságon 2001.10.04-én elérte, hogy Ideiglenes Intézkedést adjanak ki, amelyben úgy ítéltek, hogy minden adatot vissza kell szolgáltatni nekik. Az NDR bizonyítékként csak egy másolatot tartott meg, amelyet egy semleges közjegyzőnek adtak át Hamburgban, és ott egy széfbe zárták.
1.5 Összefoglalás Az említett eseményeket követően a könyv szerzője elbeszélgetett az ismert német biztonsági
szakértővel, Marc Riief-fel, a bankok biztonsági problematikájáról. Ruef pontosan ismeri a gondot, mivel néhány nagy bank biztonsági tanácsadója. A következőket mondta: „Sok bank webes fellépése megosztott. Ezzel azt akarom mondani, hogy van egy nyilvános rész, amelyet mindenki elérhet (WWW/HTTP). Azután van egy félig nyilványos terület, az e~banking, ahová csak az ügyfelek léphetnek be megfelelő azonosítást követően (WWW/SSL/SHTTP/ jelszóvédelem). A nyilvános részt elhanyagolhatják, ami gyakran így is történik (nem viszik túlzásba a biztonsági mechanizmusokat és irányvonalakat). Az e-banking területet védeni kell, és ez meg is történik (a legújabb patchek, biztosított rendszer, erős irányvonalak, megfelelő biztonsági intézkedések). A megfelelő szoftver és hardver a naplózáshoz és a biztonsághoz (pl. tűzfal-elemek és Intrusion Detection System) a pénzügyi szektorban aránylag gyakran a rendelkezésre áll (ellentétben más terület hálózati kapcsolattal működő cégeivel). Ezeknek az adminisztrációja is többnyire jó - de sajnos nem nagyon jó - kezekben van. Szerintem a bökkenő a kiértékelésnél van. Az erre hivatott rendszeradminisztrátorok, biztonsági megbízottak vagy auditorok nem tudnak mit kezdeni a biztonsági rendszer logfájljaival, mivel nincs meg a szükséges háttértudásuk. Ösz-szességében azt kell, hogy mondjam: vannak ilyenek és olyanok is. Láttam már olyan banki számítógépeket, hogy a legszívesebben abban a minutumban mondtam volna fel a folyószámlámat. És persze vannak olyan intézmények is, amelyek kitűnő kompetenciával tűnnek ki. Nem szabad valamennyit egy kalap alá venni. Mindenesetre bőven van még tennivaló..."
1.6 Sajtóbeszámolók A bank-hackelés világszerte nagy visszhangot keltett. Számtalan újság és rádióállomás számolt be az akcióról. Ebben az összefüggésben újra és újra előkerült a biztonság kérdése, íme két érdekes vélemény. A www.newsbytes.com és a www.washingtonpost.com tudósításai Német tv-s hackerek bankszervert törtek fel per van kilátásban Ned Stafford, Newsbytes MÜNCHEN, NÉMETORSZÁG 2001. szept. 17., du. 4:51 ••••, Németország egyik legnagyobb bankja, a bank szóvivője szerint jogi lépéseket tervez egy népszerű fogyasztói high-tech tv-show ellen, amely hackereket szerződtetett, hogy feltörjék a bank online banking szerverét. Cornelia Klaila, a ••• müncheni szóvivője, ezt nyilatkozta a Newsbytes-nak: „Amit tettek, az törvénytelen. Nagyon törvénytelen. Az „ők", akikre utalt, a Technikai Tanácsadó nevű tv-show, amelyet az ARD, Németország két közszolgálati tévéhálózatának egyike gyárt. A Technikai Tanácsadó augusztusban felfogadott néhány fiatalembert, hogy betörjenek a ••• online banki szerverébe, és információkat töltsenek le az ügyfelek számláiról. Az információk neveket, számlaszámokat, PIN-számokat és internetes IP-számokat tartalmaztak, amelyek fontosak a biztonságos online banki szolgáltatáshoz. A sztorit vasárnap este közvetítették. Bernd Leptihn, a Technikai Tanácsadó (Ratgeber Technik) hírszerkesztő csoportjának hamburgi vezetője azt nyilatkozta a Newsbytes-nak, hogy nem aggódik a ••• perindítása miatt. Leptihn, aki 27 éve a Technical Adviser frontembere, de most a kamera mögött dolgozik, így ékelődött: „Tudják, én 30 éve csinálok törvénytelen dolgokat. Voltak pereim ezelőtt is, de mostanáig soha nem vesztettem el egyetlen ügyet sem." Azt mondta, hogy az ARD jogi részlege szerint az ilyesfajta oknyo-mozó újságírást megengedi a német jog, ha az „a köz érdekét szolgálja". Leptihn szerint, aki amúgy jól ismert személyiség Németországban, a nyilvánosság informálása a ••• számítógépének hiányosságairól nagyon is a köz érdekében történt. „A (bankszámla) információkkal, amelyeknek a birtokába jutottunk, most akárhol is lehetnénk a világban, millió és millió euró birtokában" mondta.
Leptihn arra is utalt, hogy a kutatás megmutatta, hogy a ••• banknál bizony van néhány nagy biztonsági rés. A bank a Microsoft Internet Information Serverét (IIS 4.0) használta. A Technikai Tanácsadó megbízott egy négytagú hackercsapatot. Azt nem árulta el, hogy mennyit fizettek nekik, de ez „nem volt sok". A fiatal hackerek inkább abban voltak érdekeltek, hogy publicitást nyerjenek induló internetes biztonsági tanácsadó cégüknek - mondta. Négyük közül az egyik Stephan Weide, 22 évesen a Multimedia Network Systems cég ügyvezetője Leinefeldében. Weide azt nyilatkozta a Newsbytes-nak, hogy a betörés a ••• számítógépébe csak két-három napot vett igénybe, és „igazán nem volt gond, bárki meg tudta volna tenni." Miután a Technikai Tanácsadó vasárnap éjszaka a tévében megszellőztette az ügyet, Weide azt mondta, hogy ő és a csapata részt vettek egy telekonferenciás hívásban a ••• technikai személyzetével, hogy megmondják nekik, hogyan tudják befoltozni a réseket. Mikor megkérdeztük, hogy a technikaiak hangot adtak-e haragjuknak a hackelés miatt, azt mondta: „Nem mondtak csúnya szavakat. Azt hiszem, féltek, hogy elveszítik az állásukat." Weide és Leptihn elmondták, hogy a ••• online banking oldala vasárnap késő éjjeltől kezdve úgy hat órára leállt. Klaila, a bank szóvivője, ezt nyomatékosan kétségbe vonta, s azt állította, hogy a weboldalt a szokásos rendszeres karbantartás és nem a biztonsági rések kijavítása miatt állították le. Azt is jelezte, hogy a ••• bank ezen a nyáron egy új online weboldalt helyezett üzembe, és hogy ez az oldal state-of-the-art rendszer, ami biztonságos. Augusztus hónap folyamán - mint mondta -mindkét oldal, a régi és az új is online-ban voltak, és a hackerek a régi weboldalra, és nem az újra törtek be. A régi weboldalt szeptember elején offline-ba helyezték. Leptihn viszont vitatta, hogy az új oldal az utolsó éjszaka előtt biztonságos lett volna. „A hackereink ismét próbálkoztak az új site-on, és sikerrel jártak" -állította. Klaila azt mondta, hogy bűntetőjogi és polgári peres kártérítési per is lehetséges a Technikai Tanácsadó ellen. „Még el kell döntenünk, mit is akarunk tenni." - vélekedett. A zdnet.de News tudósítása ARD: Online banki szolgáltatásbeli hiányosságokat lepleztek le PIN-eket és TAN-eket olvastak ki bekapcsolt kamera előtt. 2001. szeptember 17., 08:46 óra Thüringiai hackerek a Ratgeber: Technik ARD-magazin megbízásából, működő kamera előtt törték fel a ••• biztonsági mechanizmusait, így a szerkesztőknek és a szakértőknek a műsor adatai szerint lehetővé vált néhány napon belül 1,5 millió online könyvelési akciót megszerezni, beleértve titkos kódokat (PIN), az online-számokat (TAN) és az IP-címeket. Ahogy az ARD a továbbiakban közölte, a hackereknek dispo-kredit adatokat is sikerült elérniük, s így, a számlákat a kimerítésig terhelhették volna. Behatolásuk bizonyítására a betolakodók csupán egy 100 márkás könyvelésre „korlátozták magukat". A tévéadó komputeres szakemberei ismételten óvtak a trójaiktól, amelyek értelmetlenné teszik a pénzintézet kódolási eljárását. Még egy laptoppal és egy adatátvitelre alkalmas mobiltelefonnnal is gond nélkül lehet jogosulatlanul pénzt átutalni. Miután a magazin figyelmeztette a •••-t központi számítógépének a hiányosságaira, egy új log-in redszert vezettek be. Az adó által felfogadott hackerek azonban ebben az átdolgozott programban is találtak réseket. A Ratgeber szerkesztősége szerint azért a •••.t választották, mert ez a bank különösen „lukacsosnak" bizonyult a jogosulatlan hozzáférésekkel szemben. De elvileg sok más banknál és takarékpénztárnál is lehetséges lenne egy virtuális betörés.
1.7 Tapaszatalatok más bankoknál Nem csak a ••• nincs felvértezve a támadások ellen, más bankoknál is csak félig-meddig
sikeresek a szerverük védelmére irányuló intézkedések.
1.7.1 Forgatókönyv a takarékpénztár-területen 2001 októberében a szerző újabb megkeresést kapott valakitől, aki a különböző bankok visszásságainak a feltárására tararékpénztárak biztonsági auditjával bízta meg. A tapasztalatokból, amelyeket az előző akciókból gyűjtöttek, a következő terv született. Nyíltszívűen - a kleinmusterhauseni takarékpénztár Ennek a tararékpénztárnak olyan az internetes megoldása, mint a legtöbbnek Németoszágban: két részből áll. Van a nyilvános rész, amelyben az ügyfél az illető tararékpénztárról információt szerezhet, és amelyen keresztül egy linkkel a folyószámlájához jut. Ez általában egészen egyszerű felépítésű. Többnyire egy helyben lévő vagy szolgáltatón keresztül kezelt szerverről van szó, amely csak nagyon egyszerűen védett, és a rendszergazda is szívesen elhanyagolja. Ezen a webszerveren gyakran tisztán reprezentatív célokból futnak olyan alkalmazások, amelyek nagyon támadhatóvá teszik a szervert. A második terület a tulajdonképpeni e-banking. Ezt a takarékpénztáraknál gyakran számítóközpontok kezelik. A szerverek többnyire jól védettek, és ki lehet indulni abból, hogy egy támadás ez ellen a számítógép ellen semmiféle sikerrel sem járna.
Bepillantás egy német tararékpénztár jelszó-fájljába, egy maghatározott URL begépelésével
Itt az átmenet a home-bankinghoz
A támadási terv Először egy biztonsági rést próbáltak keresni, amely lehetővé teszi az illető bank, illetve takarékpénztár nyilvános szerverének az elérését. Ez ebben az esetben egy script-hiba vagy egy hibás FTP-szerver lenne, amelyen többnyire HBCI-eszközök meghajtóit vagy különböző online banking szoftverek frissítéseit tárolják. A betörés után megváltoztattak minden oldalt, amelyek a számítóközpontban elhelyezett tulajdonképpeni e-banking gépre mutattak. Isten hozta a tararékpénztárnál -csak az URL-nek kell a megfelelőnek lenni
Példa egy tararékpénztári oldal forrásszövegére megfelelő linkeléssel a számítógép-központhoz
A hamisítvány veszi át a szerepet A megfelelő oldal külleméről és működési módjáról rendelkezésre álló információk alapján
hozzákezdtek egy hamisítvány felépítéséhez. Ez a hamisítvány a tuljdonképpeni e-banking számítógépet „tükrözné", tehát az ügyfeleket a helyi tararékpénztár prezentációjáról a megváltoztatott Folyószámla vagy Onlinebanking link közvetlenül a hamisítványra vezeti. Az ügyfél ugyanazokat az információkat és opciókat látja maga előtt, mint a valódi e-banking gépen. Ha most egy átutaláshoz beírja az adatokat, ezek az adatok egy logfájlban landolnak. Mivel a tranzakciók egyike sem lesz végrehajtva, hanem csak a logfájlba vándorol, a tranzakciószámok továbbra is érvényben maradnak. „A kockázatokról és mellékhatásokról kérdezze banki tanácsadóját!"
