2009. október 29., csütörtök

Nyomozás a disk defrag után

Olvasható a SANS forensics blogon két kiváló bejegyzés arról, hogy milyen módon lehet kideríteni egy munkaállomásról, hogy futtatták-e rajta a töredezettségmentesítőt. Mielőtt rátérnénk a konkrét módszerekre, kicsit járjuk körül a probémát.

Defrag 1x1
Induljunk messziről. Amikor az operációs rendszerünk letöröl egy fájlt az eleinte (jó közelítéssel) szépen, sorfolytonosan elhelyezkedő fájlok közül, akkor keletkezik egy valamekkora méretű "lyuk", azaz szabadon felhasználható terület a lemezen. Amikor úgy dönt az oprendszer, hogy ebbe a területbe fog adatot írni legközelebb, akkor ha az éppen írni akart fájl nagyobb, mint a "lyuk", akkor csak egy része fér ide bele, a maradékot máshová kell tennie, tehát fragmentálódás következik be.

A fájlrendszer feljegyzi az egyes fájlokhoz tartozó fragmentek helyét, tehát a felhasználó számára gyakorlatilag transzparens a folyamat - egészen addig, amíg az összevissza található apró fragmentek okozta lemezműveleti overhead el nem éri a türelemküszöbét. A tünet meglehetően sztereotip: bármit kezdeményez a felhasználó, bárhová kattint, a lemez elkezd kerepelni, azonban elképesztően lassan történik bármi is. A defrag pontosan ezt a problémát orvosolja: megkeresi, hogy hol vannak a fájlok fragmentjei, és egymás mögé rendezi őket.

Forensic szempontból nézve a dolgot az egyik szemünk sír, a másik viszont nem feltétlenül. Egyrészt a defrag nagyon intenzív írással járó lemezművelet, emiatt a törölhető, ám visszanyerhető adatokban gazdag részekben sokszor egyszerű eszközökkel jóvátehetetlen roncsolást okoz (még egyszer: forensic szempontból, tehát most az a célunk, hogy minél több törölt fájlt hozzunk vissza, legitim működés szempontjából ez nem számít). A másik oldalon viszont a slackekben található adatokat nem semmisíti meg a defrag, tehát teljes védelmet semmiképp sem jelent az adatvisszahozás ellen. Slacknek nevezzük azt a területet, ami az operációs által kisméretű fájok (fragmentek) esetében a lefoglalt allokációs egységben a fizikailag felülírt területen kívül helyezkedik el. Xp esetében 4096byte az allokációs egység, az NTFS-sel viszont 512byte-os szeletekben írjuk felül a lemez tartalmát - emiatt, ha egy 1byte-os fájlt írunk, akkor annak 4096byte helyet foglal le az oprendszer, aminek az első 511byte-ját nullázza ki, tehát a maradékban érintetlen marad a lemezfelület.

Vadászat a defrag.exe artifactjai után
Az újabb Windows verziókban (Xp és frissebb) a defragmentálás korlátozott mértékben bár, de automatikusan lefutó taszkként lett definiálva. Emiatt egy-egy munkaállomás vizsgálatakor el kell tudnunk különíteni, hogy mely futtatások történtek a felhasználó kezdeményezésére, és melyek az operációs rendszer automatikus karbantartási folyamatainak keretében.

Sajnos nincs egyszerű mód a defrag indításának utólagos rekonstrukciójára, ugyanis az Event logokban egészen egyszerűen nem keletkeznek bejegyzések a töredezettségmentesítéshez Xp-n. Vistán és 7-ben már igen.

A töredezettségmentesítőt alapvetően kétféleképp lehet elindítani:
  • GUI-val (Start->Programs->Accessories->System Tools)
  • parancssorból a defrag parancs kiadásával (ezt használja a rendszerfolyamat)
Bármelyik módon is történik, két bejegyzés generálódik a Prefetch mappában (C:\Windows\Prefetch), az egyik a DFRGNTFS.exe-nek, a másik a Defrag.exe-nek. A Prefetchben található információk elárulják, hogy melyik végrehajtható fájlt mikor indították el utoljára és hányszor törént előzőleg indítás.

Mit mondhatunk a két elindítási módról?

GUI
A GUI tulajdonképpen egy snap-in a Microsoft Management Console-hoz, emiatt több helyen is megtalálhatóak elindításának nyomai:
  • Prefetch-ben az MMC.exe
  • UserAssist kulcsban a dfrg.msc
  • Az MMC Recent snap-ins registry-bejegyzésében a dfrg.msc, Disk Defragmenter.lnk
  • Időpecsétek a fájlokon (dfrgntfs.exe)
  • A Disk Defragmenter.lnk linkjében
Parancssori mód
A parancssoros indítás a defrag c: paranccsal lehetséges. Keletkező nyomok:
  • Prefetch
  • layout.ini a prefetch mappában. Kis magyarázat: a fájlt a menetrend szerinti defrag nem nyitja meg, nem használja, ellentétben a felhasználó által kezdeményezettel.
  • Timeline analízissel viszonylag munkásan bár, de jól következtethetünk manuális defragmentálásra (tipikusan egymáshoz közel helyezkednek el a CMD.exe, a defrag.exe és esetleg még valami, amit megpróbált elrejteni a felhasználó/támadó)

2009. október 28., szerda

Forensic vizsgálatok 9. - Windows 7 I.

A Windows 7 magyarországi bemutatója nemrég zajlott: nézzünk kicsit körül, hogy forensic szempontból mi minden változott/javult az új verzióban.

Felhasználói profilok
Az Xp-ben alapvetően kétfajta profilt lehetett a felhasználóhoz rendelni: az a célja a dolognak, hogy a felhasználó a domain akármelyik munkaállomására beléphessen, a személyes mappái kövessék hűen. Ilyen klasszikus mappa a My Documents és a többi hasonló nevű, tipikusan a Documents and Settings mappában található. Az ilyen "letöltődő" profilokat roaming profilnak nevezik, és jellemzően pár tíz megás méret fölött ez hosszítja meg jelentősen a belépési procedúrát egy új gépen (e sorok írója egyszer elkövette azt a hibát, hogy négy-öt gigányi zenét tartott a My Documents-mappában, és csodálkozott, hogy miért tart tíz percig belépésnél a felület testreszabása).

Forensic szempontból ez egyrészt azért kellemes, ugyanis a felhasználói adatok jelentős része központilag is megtalálható, tehát ad absurdum az elveszett/letörölt/ellopott munkaállomás nélkül is lehet -korlátozott- analízist végezni. A dolog hátulütője ott van, hogy sokszor nem teljesen világos, hogy a szinkronizáció mely fájlokat érinti, és melyeket nem (tehát pl. a böngészők melyik részbe szemetelnek).

Windows7 alatt explicit meghatározták, hogy a felhasználói profil melyik része romaing és melyik local: a böngészős példánál maradva a cookie cache a roaming részben, a browsing cache és a history a localban található.

IE
Az IE forensic szempontból fontos újítása a "protected mód": azaz ha káros kódot töltene le a böngészőnk, az nem fog tudni a futás ellenére sem kárt okozni - elméletileg. Mivel nem minden felhasználói tevékenység véghezvihető ilyen módban, két mappakészletet is használ a böngészőnk. A buta módú működés során használt mappakészlet itt található:

%userprofile%\AppData\Local\Microsoft\Windows\History\Low\History.IE5


Figyeljük meg a "Low" szócskát, ugyanis nagyrészt itt találhatóak a forensic szempontból fontos dolgok (history, lnk fájlok, tmp mappák stb). A lokálisan megnyitott fájlokkal kapcsolatos dolgok a "rendes" mappakészletben találhatóak.

Persze ki is lehet kapcsolni a "Low" mappák használatát:
  • Kikapcsoljuk a "Protected mode" használatát
  • Kikapcsoljuk az UAC-ot
  • Adminisztrátorként használjuk a böngészőt(!)
Pendrive-ok
Az Xp-ben megismert és bevált artifactok túlnyomórészt változatlanul kereshetőek a 7-ben is, csak helyenként másként hívják a figyelendő logokat és registry-kulcsokat. Itt egy nagyon jó forensic manual a különféle Windows-verziók USB-kulcsokkal kapcsolatos elemzésére.

Csak címszavakban: amikor csatlakoztatunk egy USB-s tárolóeszközt a vindózunkhoz, számos artifact keletkezik, amelyek az eszköz eltávolítása után is megmaradnak. Forensic nyomozás során ezeket a nyomokat keressük, illetve elemezzük. A registryben az alábbi helyeket érdemes figyelni, csatlakoztatott eszközök nyomai után kutatva:

HKEY_LOCAL_SYSTEM\CurrentControlSet\Enum\USBSTOR\ - a csatlakoztatott eszközök azonosítói
NTUSER.DAT\Software\Microsoft\CurrentVersion\Explorer\MountPoints2 - melyik felhasználó csatlakoztatta az adott eszközt?

2009. október 19., hétfő

A gyanúsan keveset használt merevlemez

Nemrég nyomelemeztünk egy meglehetősen csúnya történetben: a kezdetben lelkes, az egész fejlesztési folyamatot egymaga végigdolgozó fejlesztőt a projekt végéhez közeledvén kirúgták, és emiatt búcsúajándékként letörölt mindent a céges fájlszerverekről, amit ért és értékes volt. Visszaadta a laptopját a főnökségnek becsomagolva, leformázva, csodaszép gyári Vistával.

Itt kapcsolódtunk be a történetbe: ha lehet, próbáljunk meg kezdeni valamit a munkaállomással - ami a szervert illeti, nyilván nem készült róla mentés, és a törlés ideje óta folyamatosan ment, néhányszor defragmentálták is. Nem, a sokmilliót érő szoftver forrása sehol máshol nem volt meg, csak Sanyinál (ő a fejlesztő). A laptop immáron másfél évvel ezelőtt került Sanyihoz, azóta csak ő használta.

A notebookban százhúsz gigás egység lakik - ekkora lemezt image-elni jó idő. Már neki is készültünk volna a műveletnek kávéval-cigarettával, mikor szembe ötlött a proszídzsör során korábban kiadott parancs kimenete. No, mi a hiba vele?

root@ubuntu:/root# smartctl -A /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0002 098 098 000 Old_age Always - 0
4 Start_Stop_Count 0x0033 099 099 020 Pre-fail Always - 6
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 36204703
9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 61
10 Spin_Retry_Count 0x0013 100 100 034 Pre-fail Always - 0
12 Power_Cycle_Count 0x0033 100 100 020 Pre-fail Always - 6
184 Unknown_Attribute 0x0033 100 253 097 Pre-fail Always - 0
187 Reported_Uncorrect 0x003a 100 100 000 Old_age Always - 0
188 Unknown_Attribute 0x0022 100 096 045 Old_age Always - 55835754519
189 High_Fly_Writes 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 055 049 040 Old_age Always - 45 (Lifetime Min/Max 17/45)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x003a 100 100 000 Old_age Always - 731
193 Load_Cycle_Count 0x0012 060 060 000 Old_age Always - 80815
194 Temperature_Celsius 0x003a 045 051 000 Old_age Always - 45 (0 13 0 0)
195 Hardware_ECC_Recovered 0x003e 080 065 000 Old_age Always - 175568345
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x003e 100 100 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x0000 200 200 000 Old_age Offline - 0
200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0
202 TA_Increase_Count 0x0000 100 253 000 Old_age Offline - 0
254 Unknown_Attribute 0x0000 100 253 000 Old_age Offline - 0

Megvan? Nincs meg? Megmutatom a lényeget:

4 Start_Stop_Count [...] 6

9 Power_On_Hours [...] 61

Tehát a SMART szerint összesen alig több, mint két napot volt bekapcsolva a winchester, és hatszor indult el a gép alatta: nagyon valószínű tehát, hogy a fejlesztő egész egyszerűen kivette a lemezt gépből, és betett helyére egy másikat. A vistásat.

2009. október 16., péntek

Forensic vizsgálatok 8.- Word dokumentumok vizsgálata

A betörési tesztelés mellett a nyomelemző munkák területe az a témakör, amelyről sok szakmabeli is csak homályos képpel rendelkezik, holott meglehetősen szerteágazó és szövevényes világról van szó. Több posztból álló sorozatunkban igyekszünk felvillantani néhány érdekesebb momentumot nyomelemzős munkáinkról.

Word dokumentumokkal mindenki találkozott már. Ilyen formátumban rengeteg anyag készül, és ennek megfelelően számos incidens kivizsgálásakor szemügyre veszünk ilyen dokumentumokat is.

A Word (és úgy alapvetően a gyakran használt Office-formátumok) fájlformátuma konténer, OLE streameket tartalmaz. Fájlszignatúra szintjén megegyezik az xls, doc stb. formátum:
root@jester:/root# file doksi.doc
doksi.doc: Microsoft Office Document
root@jester:/root#

Zárójelben megjegyezzük, hogy létezik eszköz arra, hogy összeházasítsunk Word dokumentumos és XLS-es streameket: ha az így készült állományt Worddel nyitjuk meg, word dokumentumként viselkedik, ha viszont Excellel, akkor annak rendje-módja szerint számolótábla köszön vissza ránk.

Metainformációk tekintetében több mód is használható.

Véleményezés eszköztár
Gyakori eset, amikor "bennefelejtik" a dokumentumban a véleményezési folyamat során összegyűlt kommenteket. Erről többet nem is mondanánk.

NTFS szintű adatok
A dokumentumok, ha windowsos munkaállomásokon vagy fájleszervereken találkozunk velük, NTFS partíciókon találhatóak - ebből következően az NTFS fájlrendszer által nyújtott szolgáltatásokat (timestampek, ACL-ek stb.) mindenképpen megvizsgáljuk. Természetesen lehet matatni is az időpecséteket.

Metaadatok
Ez már érdekesebb. Egy Word dokumentumhoz több szinten is találhatunk metaadatokat,ezek egy része ADS-ként tárolódik a fájl mögött, másik része magában a doksiban található.

A legnagyobb ilyen, metaadatos fiaskó Tony Blair brit miniszterelnökkel történt, amikor publikálta egy jelentést az iraki helyzettel kapcsolatban - igen ám, csak a jelentés jelentős részét lopták egy már korábbi anyagból. Elkövették azt a hibát, hogy word dokumentum formátumban publikálták az anyagot: a megfelelő eszközzel megvizsgálva a dokumentumot, meglepő metaadatokra bukkanhatunk. Például a Blair-féle dokumentum esetében:

root@jester:/root# perl wmd.pl blair.doc
--------------------
Statistics
--------------------
File = /root/blair.doc
Size = 65024 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = English (US)


Document was created on Windows.

Magic Created : MS Word 97
Magic Revised : MS Word 97

--------------------
Last Author(s) Info
--------------------
1 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - security.asd
2 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - security.asd
3 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - security.asd
4 : JPratt : C:\TEMP\Iraq - security.doc
5 : JPratt : A:\Iraq - security.doc
6 : ablackshaw : C:\ABlackshaw\Iraq - security.doc
7 : ablackshaw : C:\ABlackshaw\A;Iraq - security.doc
8 : ablackshaw : A:\Iraq - security.doc
9 : MKhan : C:\TEMP\Iraq - security.doc
10 : MKhan : C:\WINNT\Profiles\mkhan\Desktop\Iraq.doc

--------------------
Summary Information
--------------------
Title : Iraq- ITS INFRASTRUCTURE OF CONCEALMENT, DECEPTION AND INTIMIDATION
Subject :
Authress : default
LastAuth : MKhan
RevNum : 4
AppName : Microsoft Word 8.0
Created : 03.02.2003, 09:31:00
Last Saved : 03.02.2003, 11:18:00
Last Printed : 30.01.2003, 21:33:00

--------------------
Document Summary Information
--------------------
Organization : default

Jó vadászatot!

2009. október 13., kedd

Forensic vizsgálatok 7.- Windows Xp restore pointok

A betörési tesztelés mellett a nyomelemző munkák területe az a témakör, amelyről sok szakmabeli is csak homályos képpel rendelkezik, holott meglehetősen szerteágazó és szövevényes világról van szó. Több posztból álló sorozatunkban igyekszünk felvillantani néhány érdekesebb momentumot nyomelemzős munkáinkról.

A Windows Xp-ben bemutatkozott egy csodálatos új szolgáltatás, amelynek keretében a felhasználó vissza tudja állítani a rendszerét olyan régebbi állapotba, amikor működött.

Mielőtt rátérnénk arra, hogy miért is jó forensic szempontból a system restore pointok vizsgálata, kicsit fussuk át a szolgáltatást. Először is, a SRP-k alapvetően az alábbi elemeket tartalmazzák visszaállítási céllal (testre is lehet szabni a dolgot a megfelelő célszerszámmal, ez esetben új elemek is jöhetnek a listába):
  • A Registry bizonyos részei
  • Local profilok (nem roaming értelemben)
  • COM+ objektumok adatbázisa
  • A Windows File Protection DLL cache-e (emlékszünk ugye, ebből a tiszta forrásból javítja meg a windows a DLL-eket, amelyeket gonosz módon megbuherálunk kedvenc rootkitünkkel a tesztrendszerünkben)
  • WMI adatbázis
  • IIS metabase
  • Azok a fájlok, amelyeket beleteszünk a testreszabásba
Mi az, ami kimarad a visszaállításból? Figyelem: attól, hogy a visszaállításban nem szerepelnek az alábbi elemek, még biztonsági mentési céllal simán belekerülhetnek az SRP-kbe!
  • A SAM hive (asszociálunk a "felhasználók" és a "jelszavak" stringekre, és igen, bizonyos részeit biztonsági menti a Windows annak ellenére, hogy visszaállításkor nem másolja vissza őket)
  • A DRM menedzsment beállításai
  • A wifi hálózatok kulcsai
  • Azok a fájlok, amelyeket explicit kihagyunk a testreszabásban
A System Restore Service futásához meglehetősen sok hely szükséges, nagyjából 200MB szabad helynél kevesebb esetén a szolgáltatás egész egyszerűen pihenni tér, ekkor nem készülnek SRP-k, a forensic elemző pedig gondolkodhat, hogy miért is hiányzik néhány, aminek márpedig ott kéne lennie.

A System Restore Service futásával kapcsolatos információk a Registryben találhatóak, az alábbi kulcs alatt:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore
A fenti kulcsban található értékek mindent elárulnak a szolgáltatás paraméterezéséről:
  • A DisableSR szabályozza, hogy be legyen-e kapcsolva a szolgáltatás.
  • Az RPGlobalInterval mondja meg, hogy milyen gyakran készül SRP.
  • Az RPLifeInterval mutatja meg, mennyi legyen az SRP-k élettartama, alapkiépítésben 7776000 másodperc, azaz 90 nap.
Mire használhatóak az SRP-k? Egyrészről registry mentéseket tartalmaznak. Az SRP-kben egyébként rengeteg, forensic szempontból fontos fájl megtalálható, például:
  • Majdnem a teljes registry
  • RP.log: megtalálható benne az SRP típusa, némi szöveges információ a keletkezés körülményeiről, egy 64 bites FILETIME objektum, amiből meglehetősen pontosan megvan, mikor készült a mentés a rendszeróra szerint. Ez utóbbinak ott van jelentősége, hogy az RP-oknak egyedi szekvenciális sorszámuk van, és ha az idő összevissza telik az RP-k sorszámait tekintve, akkor nagy valószínűséggel machináltak a rendszeridővel akkoriban.
  • Change.log.x fájlok: ha egyszer elkészült az SRP, akkor a visszaállítható fájlokat továbbra is figyeli a rendszer, a fájlokon bekövetkezett változásokról napló készül (igaz, bináris).

Olvassatok néha CD-jogtárat

Mi mindenbe botlik az ember, ha a jogtárban nézegeti a BTK.300§-as paragrafusához tartozó magyarázatokat és határozatokat. :)

Érdemes végigolvasni, én nagyot nevettem a felmerült probléma megoldásán. Mostanában valahogy benne van a levegőben az, hogy a fejlesztők valamilyen visszaélést követnek el a munkaadó (megbízó) kárára - vajon a nehéz gazdasági helyzet teszi...? A sztori nem mai, de tessék-tessék, olvassatok. Egy kávé elfogyasztása alatt megvan.
BH1999. 145.
A számítógépes csalás bűntettének a kísérletét valósítja meg, aki a
számítógépes adatfeldolgozás eredményét meg nem engedett művelet
végzésével, nevezetesen vírusok becsempészésével tudatosan akként
befolyásolja, hogy ezáltal a programok működésre képtelenné váljanak, és
így a sértettnek ebből kára származhat [Btk. 16. §, 300/C. § (1) bek.].
A városi bíróság a vádlottat bűnösnek mondta ki számítógépes csalás
bűntettében [...].
A vádlott 1991. október 1. napjától munkaviszonyban állt az R. Kft.-nél,
a munkáját azonban kirendelés alapján a K. gyáregységében végezte. Az
1992. október 1. napján létesített munkaszerződés szerint a vádlott
munkaköri leírása alapján feladata volt az üzemet átfogó
számítástechnikai rendszer kidolgozása, annak gyakorlati alkalmazása,
illetve a vevői igényeknek megfelelő termelés szervezése, követése és a
gépi adatfeldolgozók szakmai irányítása. A vádlottat terhelte a
számítástechnikai adatok tekintetében a pontos adatszolgáltatásért való
felelősség. A munkaköri leírásban szereplő feladatok ellátásáért a
vádlott havi bérezésben részesült.
A vádlott a munkaszerződésben foglalt kötelezettsége alapján a
gyáregység részére 4 db programot írt, amelyek a vállalat
gazdálkodásának regisztrálásában, az ügyvitel szervezésében és a vezetői
információ adásában működtek közre. A vádlott az általa megírt két
programba - pontosan meg nem határozható időben - olyan kódsorozatot
épített be, amely az aktiválását követően a programokat fizikálisan
megsemmisíti, a harmadik programba pedig olyan kódsorozatot épített be, amely egy meghatározott naptári időpont bekövetkezése után a program működését - annak fizikai rombolása nélkül, a program végtelen ciklusba juttatásával - lehetetlenné teszi. A vádlott az általa kiépített
rendszerre vonatkozóan a romboló rutinok beépítéséről a munkáltatóját
nem tájékoztatta.
Amikor 1996. év tavaszán a vádlott és a kft. tulajdonosa között a
számítógépes rendszer tulajdonjoga tekintetében vita alakult ki, a
munkáltató a vádlott foglalkoztatását 1996. április hó 2. napján
azonnali hatállyal megszüntette.
Miután a munkáltatónak nem volt tudomása a működő rendszerbe épített
romboló motívumokról, a programok 1996. április 11-én és a 28-át követő
napon magukat részben megsemmisítették, illetve működésképtelenné
váltak, így a gyáregységnél a termelés irányítása, regisztrálása és az
árukiadás kb. 1 napra lehetetlenné vált. A leállást követően a vállalat
munkatársai a számítógépes rendszert beindították úgy, hogy a mindenkor
esedékes időpont (év, nap, hó) az év vonatkozásában visszadátumozásra
került. A rendszer a mai napig visszadátumozva működik.
A vádlott magatartásával a gyáregységnek mintegy 500 000-600 000 forint
kárt okozott, amely a rendszer kijavításával merült fel.
Az elsőfokú bíróság ítélete ellen a vádlott és a védője felmentés végett
jelentett be fellebbezést, amit a másodfokú tárgyaláson is fenntartottak.
A megyei főügyész az elsőfokú bíróság által megállapított tényállás
kiegészítése mellett az elsőfokú bíróság ítéletének a helybenhagyását
indítványozta.
A megyei bíróság az elsőfokú bíróság ítéletét felülbírálva azt
állapította meg, hogy az elsőfokú bíróság az ügyet alapvetően
felderítette, a tényállást a rendelkezésre álló bizonyítékok egyenként
és összességében történő okszerű mérlegelése alapján állapította meg,
ami azonban az iratok alapján a Be. 258. §-a (1) bekezdésének a) pontja
alapján kiegészítésre szorul, az alábbiak szerint.
A vádlott a romboló rutinokat és a programokat végtelen ciklusba küldő
kódrészletet 1994. évben - közelebbről meg nem határozható időpontban -
építette be a programokba, a romboló hatást időről időre aktiválni és
deaktiválni kellett. A vádlott magát a védelmet is megváltoztatta.
A programba épített romboló rutint 1995. november 3-án módosította a
vádlott 1996. január 17-i lejárati idővel, ezt a rutint azonban nem
aktiválta, így a programban kár nem keletkezett.
A vádlott a programot 1995. november 2-án módosította, akkor lejárati
időnek 1996. január 17-ét jelölte meg, ezt követően a lejárati időt
1996. január 16-án és március 20-án április 28-ára állította be, a
végtelenített ciklusba küldő kódrészletet pedig aktiválta.
A vádlott a foglalkoztatásának megszűnésekor, 1996. április 2-án - de
azt követően sem - a beépített vírusrendszerű programrészletekről a
munkáltatóját nem tájékoztatta, így azok a lejárat időpontjában a
programokban működésbe léptek, azokat használhatatlanná téve. A
programok működésképtelensége addig tartott, amíg a rendszer
visszadátumozásával ismét működőképes állapotba nem helyezték. A
rendszer a mai napig is működik.
A romboló rutinokat kizárólag olyan személy építhette be a programba,
akinek birtokában volt a forráskód, a programok dokumentációja, és a
fejlesztőnyelvet is használni tudta. A sértett cégnél ezekkel az
anyagokkal és tudással kizárólag a vádlott rendelkezett.
A beépített romboló rutinok és a végtelenített ciklusba juttató
kódrészlet a tárolt információkat, adatokat nem, kizárólag a programot
védte. Azok beépítése a vádlotton kívül a többi felhasználó előtt nem
volt felismerhető, így aktiválható és deaktiválható sem. A beépítés
kizárólag azt a célt szolgálta, hogy szükség esetén a vádlott a
programok működését lehetetlenné tegye.
A fenti kiegészítésekkel az elsőfokú bíróság által megállapított
tényállás megalapozott, és a felülbírálat során is irányadó volt.
A felmentésre irányuló fellebbezések nem alaposak.
A tanúvallomásokból, de különösen a szakértői véleményből egyértelműen
megállapítható, hogy a vírusszerű részeket a vádlott szándékosan
építette be a programokba, azokat szándékosan aktiválta, a vírusszerű
részek beépítéséről, de a deaktiválás lehetőségéről sem tájékoztatta a
sértett vállalatot; egyébként maga a vádlott is elismerte, hogy ezeknek
a részeknek a programba történő beépítéséről senkit nem tájékoztatott.
Mindezekre figyelemmel az elsőfokú bíróság helyesen vetette el a
vádlottnak azt a védekezését, hogy a romboló rutinok beépítésére
adatvédelmi célokból volt szükség. A vádlott részéről a romboló rutinok
beépítésére nyilvánvalóan azért került sor, hogy az általa
kifejlesztett, de a munkáltatója tulajdonában levő programot nélküle ne
lehessen üzemeltetni.
Mindezekre figyelemmel a vádlott felmentésére nem kerülhetett sor.
Az elsőfokú bíróság az irányadó tényállás alapján törvényesen vont
következtetést a vádlott bűnösségére, a cselekmény jogi minősítése
azonban téves.
A számítógépes csalás bűntettének jogi tárgya a számítógépek
memóriájában tárolt adatok biztonságába vetett bizalom, ezen keresztül a
vagyonvédelem és a tulajdoni viszonyok védelme, az elkövetési tárgy
pedig a számítógépes adatfeldolgozás eredménye.
Az elkövetési magatartás: a program megváltoztatása, törlése, hiányos
adatok betáplálása és egyéb meg nem engedett műveletek végzése. Az adott
esetben az utóbbiról van szó, amelynél elsődleges helyet foglal el a
vírusok becsempészése.
Ez a bűncselekmény célzatos, mely jogtalan haszonszerzésre vagy kár
okozására irányul. Az adott esetben jogtalan haszonszerzésről
nyilvánvalóan nem lehet beszélni, a kárnak eredmény formájában kell
jelentkeznie, így a károkozást eredményező fordulat esetében a
cselekménynek eredménye van: a program megváltoztatása és az ebből adódó
kár. Befejezetté a cselekmény a kár bekövetkezésével válik, mindaddig,
amíg a program megváltoztatása károkozással nem jár, a cselekmény
kísérleti szakban van. A kár fogalmát a Btk. 333. §-ának 2. pontja
határozza meg, mely szerint kár a bűncselekménnyel a vagyonban okozott
értékcsökkenés. Ez pedig a megyei bíróság megítélése szerint nem lehet
az a túlóraként kifizetett munkabér, ami a rendszer átprogramozásához
szükséges idő miatt került kifizetésre.
Miután szándékos bűncselekményről van szó, a megállapított tényállásból
levonható az a következtetés, hogy a vádlott tisztában volt azzal, hogy
cselekménye az adatfeldolgozás eredményét megváltoztatta, és
belenyugodott abba, hogy cselekménye kárt okoz, ez a kár azonban a
rendszer újraindítása miatt nem következett be a sértett vállalat
vagyonában. Így a megyei bíróság megítélése szerint a vádlott a Btk.
300/C. §-ának (1) bekezdésében meghatározott számítógépes csalás
bűntettének a Btk. 16. §-a szerinti kísérletét valósította meg. Ezért a
megyei bíróság az elsőfokú bíróság ítéletét eszerint megváltoztatta.
Enyhítésre irányuló fellebbezés nem volt ugyan, ennek a lehetőségét is
vizsgálta azonban a megyei bíróság. E körben megállapította, hogy az
elsőfokú bíróság a bűnösségi körülményeket helyesen tárta fel, további
enyhítő körülmény, hogy a cselekmény kísérleti szakban maradt. Ennek
ellenére az elsőfokú bíróság az enyhítő rendelkezés alkalmazásával
inkább enyhe, mint eltúlzott büntetést szabott ki, így a büntetés
enyhítésére nem kerülhetett sor.
A fentiekre figyelemmel a megyei bíróság a cselekmény minősítésének
megváltoztatásán túl az elsőfokú bíróság ítéletét helybenhagyta.
(Szabolcs-Szatmár-Bereg Megyei Bíróság 2. A. Bf. 1150/1997. sz.)

2009. október 1., csütörtök

VoIP biztonság 1. - Bevezetés

A VoIP az, ami kihozta a switcheket az alagsorból. Alapvetően arról van ugye szó, hogy az adatátviteli hálózatba valamilyen módon hangot eresztünk, a túlvégen pedig hanggá alakítva a hálózati forgalmat gyakorlatilag feltaláltuk a madzaggal összekötött konzervdobozok új generációját.

A VoIP melletti érvként szokták azt felhozni, hogy költséget lehet csökkenteni a bevezetésével - válság sújtotta időkben ez komoly érv. A másik oldalról kevesebb szó esik: a VoIP bevezetésével jóval komolyabb hálózati infrastruktúrára, képzettebb üzemeltetőkre van szükség, ami nagy hálózatok esetében már nem kis költséget eredményez.

A VoIP a biztonságot illetően rengeteg hendikeppel indul. Első körben ott van kapásból az, hogy az IP-t nem "Vo"-ra találták ki: a TCP/IP protokollstack kialakításakor nem volt szempont a valósidejű kommunikáció igénye, ami létfontosságú a VoIP használatakor. Erre a problémára hálózati eszközök révén próbálnak megoldást adni a gyártók: visszás helyzet az, hogy egy "converged network"-ön (amelynek a nevéből fakadóan együtt kéne vinnie a hangot a többi adattal) mindenféle Layer2-es és Layer3-as technikákkal próbálják mégis elkülöníteni a kétféle forgalmat, ugyanis a valósidejű kommunikáció szempontjából egy-két elvesztett csomag nem probléma, viszont a késleltetést nem viseli el az üzemszerű használat - pont ellentétben a hagyományos adatforgalommal.

Másrészt a VoIP ott is vérzik, hogy számtalan jelzés- és hangátviteli protokoll használható hangtovábbításra, viszont ezek egy része jogilag zárt (pl. a Skype forgalma).

Harmadrészt ott akkor is problémába ütközünk, amikor "hagyományos" hálózatiforgalom-szabályozó eszközökön próbáljuk keresztülvinni a hangforgalmat: mindkét elterjedt protokoll külön csatornát használ a jelzések átvitelére, mint a hangéra, és ezen forgalom sok esetben kevéssé rögzített TCP portok között zajlik, emiatt nehezen tűzfalazható. A NAT-olás meg végképp megöli a dolog biztonságát, ugyanis a H.323 és a SIP nem, vagy csak nagyon nehezen titkosítható NAT esetén.

Összegezve azt mondhatjuk, hogy a VoIP - mivel IP fölött zajlik - ötvözi a hagyományos TCP/IP protokollstack sebezhetőségeit újabbakkal. A klasszikus ARP poisoning, floodolás, ICMP-üzenetinjektálás, sniffelés satöbbi remekül működik a legtöbb VoIP hálózatban, cserébe a SIP önmagában is hoz újabb támadási vektorokat a képbe.

A sorozat további részeiben sorra vesszük a VoIP sebezhetőségeit.