NEUMANN JÁNOS INFORMATIKAI KAR
SZAKDOLGOZAT
OE-NIK 2010
VÁRFALVI TAMÁS MILÁN NIK-O-NI-06-346
Óbudai Egyetem Neumann János Informatikai Kar Informatikai Rendszerek Intézet
SZAKDOLGOZAT FELADATLAP
Várfalvi Tamás Milán NIK-O-NI-06-346
Hallgató neve: Törzskönyvi száma:
A dolgozat címe: Sérülékenységvizsgálat a gyakorlatban Ethical hacking in practice
Intézményi konzulens: Külső konzulens:
Dr. Broczkó Péter
Beadási határidő:
2010. május 21.
A záróvizsga tárgyai:
Architektúrák Informatikai rendszermérnök
A feladat Ismertesse a számítógépes hálózatokat fenyegető támadásokat, különös tekintettel az aktuálisokra. Alakítson ki egy olyan követelményrendszert, mely bemutat egy webszerverre irányuló sérülékenységvizsgálati szolgáltatást és annak folyamatát. Mutasson be és valósítson meg egy olyan éles támadás-sorozatot, mely rámutat egy valós rendszer sérülékenységeire. Úgy dokumentálja le a támadásokat, hogy azokat utána reprodukálni lehessen. Értékelje a kapott eredményeket és mutasson rá a továbbfejlesztési lehetőségekre.
A dolgozatnak tartalmaznia kell:
számítógépes hálózatokat fenyegető, jellemző támadásokat, a tesztelendő webszerver és annak környezete ismertetését, a tesztelendő webszerverre irányuló sérülékenységvizsgálati szolgáltatás bemutatását, a sebezhetőségre irányuló vizsgálatok megtervezését, a vizsgálatok reprodukálási célú dokumentálását, a kapott eredmények értékelését, a továbbfejlesztési lehetőségeket, kitérve a felhasználó számára adott biztonsági javaslatokra, a szükséges dokumentumokat (nyilatkozat, megbízás, szerződés) és a kapott eredmények listáit csatolja mellékletben.
Ph. …...……………. Dr. Szeidl László intézetigazgató A szakdolgozat elévülésének határideje: 2012. május 21. (BMF TVSz 26.§ 9. pont szerint) A dolgozatot beadásra alkalmasnak tartom: ..……………………. intézményi konzulens
HALLGATÓI NYILATKOZAT
Alulírott záróvizsgázó hallgató kijelentem, hogy a szakdolgozat saját munkám eredménye. A felhasznált szakirodalmat és eszközöket azonosíthatóan közöltem. Egyéb jelentősebb segítséget nem vettem igénybe. Az elkészült szakdolgozatban talált eredményeket az egyetem, a feladatot kiíró intézmény saját céljaira térítés nélkül felhasználhatja.
Budapest, 2010. május 20.
................................................. hallgató aláírása
Konzultációs Napló helye
-1-
1. TARTALOMJEGYZÉK
1.
TARTALOMJEGYZÉK ................................................................................... 1
2.
ÁBRAJEGYZÉK .............................................................................................. 2
3.
IRODALOMKUTATÁS .................................................................................. 3
3.1.
Bevezetés ..................................................................................................... 3
3.2.
Az OSI referenciamodell és a TCP/IP protokollstruktúra ........................... 4
3.3.
Eszközök...................................................................................................... 7
3.3.1.
Szabad szoftverek (Open source) ......................................................... 7
3.3.2.
Fizetős szoftverek ................................................................................. 8
3.4.
Támadások osztályozásának lehetőségei ..................................................... 9
3.4.1.
Komplexitás.......................................................................................... 9
3.4.2.
Főbb módszerek.................................................................................. 10
3.4.3.
Cél....................................................................................................... 11
3.5. 4.
A kivédés lehetőségei ................................................................................ 19 GYAKORLATI PÉLDA ................................................................................ 20
4.1.
A feladat bemutatása ................................................................................. 20
4.2.
A szolgáltatás bemutatása a gyakorlatban ................................................. 24
4.2.1.
A vizsgált hálózat bemutatása ............................................................ 25
4.2.2.
Mérések előkészítése .......................................................................... 27
4.2.3.
Első mérés .......................................................................................... 32
4.2.4.
Második mérés.................................................................................... 34
4.2.5.
Harmadik mérés.................................................................................. 36
4.2.6.
Negyedik mérés .................................................................................. 38
4.2.7.
Kiértékelés .......................................................................................... 40
4.2.8.
A sérülékenységek kijavítása és a megismételt mérés bemutatása .... 46
4.2.9.
Továbbfejlesztési lehetőségek ............................................................ 48
5.
ÖSSZEFOGLALÁS ....................................................................................... 49
6.
ABSTRACT.................................................................................................... 50
7.
IRODALOMJEGYZÉK ................................................................................. 51
8.
MELLÉKLETEK............................................................................................ 53
-2-
2. ÁBRAJEGYZÉK
1. ÁBRA: AZ OSI MODELL ÉS A TCP/IP PROTOKOLLSTRUKTÚRA KAPCSOLATA [1] ...........................................................4 2. ÁBRA: A BACKTRACK LINUX DISZTRIBÚCIÓ[4] ......................................................................................................7 3. ÁBRA: A TENABLE SÉRÜLÉKENYSÉGVIZSGÁLÓ ESZKÖZE: A NESSUS[5] ........................................................................8 4. ÁBRA: A SEGÉDPROGRAMOK KOMPLEXITÁSA ÉS AZ AZOKHOZ SZÜKSÉGES TUDÁS VÁLTOZÁSA..........................................9 5. ÁBRA: A WIRESHARK HASZNÁLAT KÖZBEN[9] ....................................................................................................11 6. ÁBRA: PORT SCANNING: AZ NMAP HASZNÁLAT KÖZBEN[11] .................................................................................12 7. ÁBRA: TRUST EXPLOITATION TÁMADÁS .............................................................................................................15 8. ÁBRA: MAN-IN-THE-MIDDLE TÁMADÁS ............................................................................................................15 9. ÁBRA: DOS TÁMADÁS I.[13] ..........................................................................................................................16 10. ÁBRA: DOS TÁMADÁS II.[13] .......................................................................................................................17 11. ÁBRA: DDOS TÁMADÁS ...............................................................................................................................18 12. ÁBRA: A QUALYSGUARD FELHASZNÁLÓI FELÜLETE ............................................................................................21 13. ÁBRA: A VIZSGÁLT HÁLÓZAT LOGIKAI TOPOLÓGIÁJA ...........................................................................................25 14. ÁBRA: A MÉRÉSEK TULAJDONSÁGAI................................................................................................................27 15. ÁBRA: OPTION PROFILE ...............................................................................................................................28 16. ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: SCAN ..........................................................................................29 17. ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: MAP ..........................................................................................30 18. ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: ADDITIONAL.................................................................................31 19. ÁBRA: ELSŐ MÉRÉS BEÁLLÍTÁSA .....................................................................................................................32 20. ÁBRA: ELSŐ MÉRÉS FUTÁS KÖZBEN ................................................................................................................33 21. ÁBRA: ELSŐ MÉRÉS ÖSSZEGZÉSE ....................................................................................................................33 22. ÁBRA: MÁSODIK MÉRÉS BEÁLLÍTÁSA...............................................................................................................34 23. ÁBRA: MÁSODIK MÉRÉS FUTÁS KÖZBEN ..........................................................................................................35 24. ÁBRA: MÁSODIK MÉRÉS ÖSSZEGZÉSE..............................................................................................................35 25. ÁBRA: HARMADIK MÉRÉS BEÁLLÍTÁSA .............................................................................................................36 26. ÁBRA: HARMADIK MÉRÉS FUTÁS KÖZBEN ........................................................................................................37 27. ÁBRA: HARMADIK MÉRÉS ÖSSZEGZÉSE ............................................................................................................37 28. ÁBRA: NEGYEDIK MÉRÉS BEÁLLÍTÁSA ..............................................................................................................38 29. ÁBRA: NEGYEDIK MÉRÉS FUTÁS KÖZBEN ..........................................................................................................39 30. ÁBRA: NEGYEDIK MÉRÉS ÖSSZEGZÉSE .............................................................................................................39 31. ÁBRA: A CROSS-SITE SCRIPTING SÉRÜLÉKENYSÉG BEMUTATÁSA ...........................................................................44 32. ÁBRA: AZ ELSŐ MÉRÉS RÉSZLETES EREDMÉNYE (RÉSZLET)....................................................................................47 33. ÁBRA: AZ UTOLSÓ MÉRÉS RÉSZLETES EREDMÉNYE (RÉSZLET)................................................................................47 34. ÁBRA: ÜTEMEZETT MÉRÉS BEÁLLÍTÁSA............................................................................................................48
-3-
3. IRODALOMKUTATÁS 3.1. Bevezetés Napjainkban elképzelhetetlenné vált egy cég működtetése informatikai eszközök használata nélkül; elég, ha csak a munkaállomásokra vagy az azokat kiszolgáló szerverekre gondolunk. Bár a vállalatok fejlődése magával vonja az eszközpark fejlesztését is, ez biztonságtechnikai értelemben általában nem követi a kívánt fejlődési ütemet, és ami még tovább rontja a helyzetet, ez ki sem derül addig, amíg egy, a céget kompromittálni kívánó személy ki nem használja annak hiányosságait. Ez jelenthet információhoz való illetéktelen hozzáférést (kémkedés), szolgáltatás megbénítását, anyagi haszonhoz jutást, stb. Minden szoftverben, és egyben minden frissítésben is megtalálhatóak biztonsági rések, amelyeket kellő mennyiségű háttérismerettel, tapasztalattal és türelemmel ki lehet használni, ezért belátható, hogy feltörhetetlen rendszer nem létezik. A kockázat egyenesen arányos a kár értékével és az esemény bekövetkezésének a valószínűségével. Mivel a védeni kívánt eszközök és információ értéke adott, a bekövetkezés valószínűségét kell csökkenteni minimálisra. Ehhez naprakész biztonsági eszközökre és azok rendszeres frissítésére van szükség, továbbá ismerni kell azokat a technikákat, amelyeket a támadók felhasználhatnak a sikeres behatolás folyamatában. Mivel a cégek adminisztrátorai általában elfogultak az általuk fenntartott rendszerrel kapcsolatban, előfordulhat, hogy abban egy létfontosságú sérülékenységet nem vesznek észre. Az elmúlt években egyre több olyan informatikai tanácsadó cég jelent meg a piacon, amely titoktartási nyilatkozat betartása mellett vállalja, hogy független szakértői segítségével teszteli le a megbízó fél informatikai eszközeinek a sebezhetőségét, továbbá az eredményeket dokumentálja, és azt átadja az adott vállalatnak. Ezt a folyamatot hívják Ethical hackingnek. Szakdolgozatomat abból a célból készítettem, hogy bemutassam a sérülékenységvizsgálat jelentőségét, a támadási formák többségét, továbbá bemutassam az Ethical hackinget, mint szolgáltatást, egy információbiztonsági tanácsadó cég szemszögéből.
-4-
3.2. Az OSI referenciamodell és a TCP/IP protokollstruktúra A
hálózati
kommunikáció
alapjául
az
ISO
(International
Organization
for
Standardization, magyarul Nemzetközi Szabványügyi Szervezet) egy referenciamodellt hozott
létre,
amelyet
az
1970-es
évek
végéig
szabványként
javasolt.[1]
A gyakorlatban a modell ilyen tisztán ritkán volt megtalálható, a legelterjedtebb gyakorlati
megvalósítása
a
TCP/IP
protokollstruktúrában
valósult
meg.
Mindkét modellre jellemző, hogy a rétegek tisztán megfogalmazott, egyedi feladatokat látnak el, és ezek kizárólag az alattuk vagy a felettük álló réteggel képesek kommunikálni. Az 1. ábrán bemutatom a két modell közötti összefüggést azok rétegeinek szempontjából. A végpontokon a rétegek közöt virtuális kapcsolat épül ki. OSI modell
TCP/IP modell
Alkalmazási réteg Megjelenítési réteg Együttműködési réteg
Alkalmazási réteg
Szállítási réteg
Szállítási réteg
Hálózati réteg
Hálózati réteg
Adatkapcsolati réteg
Adatkapcsolati réteg
Fizikai réteg
1. ÁBRA: AZ OSI MODELL ÉS A TCP/IP PROTOKOLLSTRUKTÚRA KAPCSOLATA [1]
A hálózati kommunikáció során a csomagokat megvizsgálva azt tapasztaljuk, hogy azok egymásba ágyazott szerkezetetet mutatnak. Ezt mutatja be egyszerűsítve az alábbi ábra:
-5-
Az OSI referenciamodell rétegeinek rövid leírása (alulról felfelé haladva): 1. Fizikai réteg: Minden olyan feladatkör ide tartozik, amely elősegíti az adatáramlás fizikai megvalósítását, például: kábelek és csatlakozók kialakítása, jelérzékelés, analógdigitális jelátalakítás. A rétegre jellemző de facto szabvány az Ethernet, amelynek az adatkapcsolati réteggel is együtt kell működnie. A réteghez társítható hálózati eszközök: ismétlő (repeater), hub. 2. Adatkapcsolati réteg: A réteg feladata, hogy két hálózati eszköz között a szabványoknak megfelelő hálózati kereteket (frame) lehessen továbbítani, továbbá megvalósuljon a fizikai rétegben keletkezett hibák javítása. Az eszközök fizikai címzését jellemzően MAC címmel valósítják meg. A réteghez társítható hálózati eszközök: híd (bridge), switch (kapcsoló). 3. Hálózati réteg: Ez a réteg a hálózatok közötti forgalom közlekedését biztosítja. Feladata továbbá, hogy az alternatív útvonalak közül az eszközökben rendelkezésre álló információk alapján adott algoritmusokkal kiszámolják az optimális útvonalat. A réteg része a TCP/IP modellben megtalálható ICMP protokoll is, amely a hálózati problémákat hivatott detektálni és jelezni. A réteghez tartozó hálózati eszköz a forgalomirányító (router). 4. Szállítási réteg: A réteg feladata, hogy a hálózati adatforgalom a két fél között konzisztens maradjon. Két fő protokollt tartalmaz, a TCP –t (Transmission Control Protocol) és az UDP (User Datagram Protocol). A TCP protokoll olyan adatforgalom használata esetén szükséges, amely nem engedheti meg sem csomagok elvesztését, sem azok sorrendjeinek felcserélődését, ezek megoldására hibajavító eljárásokat tartalmaz. UDP csomagok esetében megengedhető a csomagok bizonyos mértékű hiánya, ha a sebesség az elsődleges szempont (a TCP protokoll a hibajavítás miatt jóval lassabb). Az UDP csomagokat jellemzően internetes médiaszolgáltatásoknál (rádió, televízió, stb.), valamint hálózaton futtatható játékszoftverek használata alkalmazzák.
-6-
5. Együttműködési réteg: A réteg legfontosabb feladata az, hogy a szállítási rétegben kialakított kapcsolatot fenntartsa. Ehhez úgynevezett sessiont alakít ki (ezért is nevezik Session layer –nek ezt a réteget). A TCP protokoll a háromutas kézfogás módszert használja fel ehhez. 6. Megjelenítési réteg: Ahhoz, hogy a címzett rendszerén az adott csomagban található adat a számára megfelelő formába kerülhessen, a megjelenítési réteg szolgáltatását kell igénybevenni. Itt történhet meg legkorábban egy adott szöveges állomány karakterkészletének konvertálása, titkosítás és fejtés, tömörítés és visszaállítás. A Little Endian – Big Endian tárolási módok közötti átalakítás is itt történhet meg. 7. Alkalmazási réteg: A felhasználóval közvetlenül kapcsolatban lévő réteg. Az alkalmazási rétegből érkező igényeket az alatta lévők képesek feldolgozni. Erre a rétegre jellemző protokollok például: FTP, Telnet, HTTP, SMTP, NTP. Az adatok feldolgozásának sorrendjét és átvitelét az alábbi ábra szemlélteti: Alkalmazási réteg
Alkalmazási réteg
Megjelenítési réteg
Megjelenítési réteg
Együttműködési réteg
Együttműködési réteg
Szállítási réteg
Szállítási réteg
Hálózati réteg
Hálózati réteg
Adatkapcsolati réteg
Adatkapcsolati réteg
Fizikai réteg
Fizikai réteg
Host 1
Host 2
A támadások végrehajtásához túlnyomórészt a hálózati rétegben megtalálható ICMP, és az együttműködési rétegben lévő TCP protokollokat használják fel.
-7-
3.3. Eszközök A sérülékenységvizsgálathoz használt szoftvereket többféleképpen lehet csoportosítani, például tudásuk, kezelhetőségük vagy hozzáférhetőségük alapján, a dolgozatban ez utóbbit választottam. 3.3.1. Szabad szoftverek (Open source) A szabad (vagy nyílt forráskódú) szoftverek általános jellemzője az, hogy bizonyos feltételeket betartva, bárki számára hozzáférhető és módosítható annak forráskódja. Éppen ebből fakad a legnagyobb előnye ennek az újszerű felfogásmódnak, miszerint lelkes szakértők ezrei dolgozhatnak együtt például a legfrissebben felfedezett biztonsági rések befoltozásán, és a felhasználóknak semmilyen költségbe nem kerül az ilyen módon elkészített illetve továbbfejlesztett szoftverek használata. A dolgozat témájába vágó operációs rendszert, a BackTrack linux disztribúciót[4] éppen a behatolástesztelésre fejlesztették ki rengeteg elemzőszoftverrel ellátva, mint például a Nmap portscanner alkalmazás, amelyről később még szót fogok ejteni.
2. ÁBRA: A BACKTRACK LINUX DISZTRIBÚCIÓ[4]
-8-
3.3.2. Fizetős szoftverek A fizetős szoftvereknek a szabad szoftverekkel szembeni legnagyobb előnyük az, hogy a fejlesztő cég folyamatos támogatást (support) nyújt a felhasználók számára, valamint egyéb szolgáltatásokat is nyújthatnak. Az sem ritka, hogy bizonyos mértékű garanciát vállalnak a termékük működésére. Bár a szabad szoftverek felhasználhatóak üzleti célokra is, egy vállalkozásnak szüksége lehet támogatásra, így a vezetőségnek kell döntenie arról, hogy megéri-e azok használata, vagy sem. Fizetős sérülékenységvizsgáló alkalmazás például a Nessus.[5]
3. ÁBRA: A TENABLE SÉRÜLÉKENYSÉGVIZSGÁLÓ ESZKÖZE: A NESSUS[5]
Természetesen a fizetős szolgáltatásoknak léteznek próbaváltozatai, amelyek vagy időkorlátosak, vagy a hozzáférhető funkciókat csökkentik le. Az általam kipróbált szolgáltatást a Qualys vállalat nyújtja QualyGuard[6] néven, ehhez 30 napos hozzáférést kaptam, amelyet a Proyet Kft. műszaki igazgatója biztosított a számomra. Ezzel a felhasználói fiókkal az összes funkció kipróbálására jogosult lettem. Létezik ugyanakkor olyan lehetőség is, amely segítségével ingyenesen vehetjük igénybe a szolgáltatást, de például a kimutatásokat csak PDF formátumban kaphatjuk kézbe. Ennek kipróbálásához a Qualys internetes portálján kell regisztrálni.
-9-
3.4. Támadások osztályozásának lehetőségei A támadásokat sokféle képpen lehet csoportosítani, én ezek közül három módszert mutatok be. Először azt vizsgálom meg, hogy mennyi háttérismeretet és előkészítést igényelnek a támadások, majd a főbb módszerek alapján osztályozom őket, végül a lehetséges támadási okokat mutatom be. 3.4.1. Komplexitás Struktúrált Az 1980-as években még sokkal nehezebb dolguk volt a szakembereknek, ha kompromittálni akartak egy célpontot. Szükségük volt a technológiák, protokollok alapos ismeretére, idegen nyelvű irodalmakra és rengeteg türelemre. A segédszoftverek akkoriban még kezdetlegesek voltak, a szaktudásra nehezebb volt szert tenni. Nem-struktúrált Napjaink támadásaira jellemző. Rengeteg segédprogram (toolkit) található meg az interneten használati utasítással együtt, továbbá fórumok és cikkek, amik a témában való elmélyülést segítik. Ha valaki támadást akar indítani, azt akár néhány kattintással is megteheti, nem igényel alapos tervezést sem. Belátható, hogy a toolkitek komplexitása és a támadásokhoz szükséges előismeretek nagysága fordítottan arányos.
4. ÁBRA: A SEGÉDPROGRAMOK KOMPLEXITÁSA ÉS AZ AZOKHOZ SZÜKSÉGES TUDÁS VÁLTOZÁSA
- 10 -
3.4.2. Főbb módszerek Buffer overflow Buffer túlcsordulásról akkor beszélünk, amikor egy eszköz memóriájába nagyobb mennyiségű adatot helyezünk el, mint amennyit kezelni tudna, ennek eredménye képpen adatokat vagy futtatható parancsokat tudunk eltárolni benne. [7] A módszerrel eszköz- és alkalmazásfüggő eredményeket lehet elérni, például jogosultságellenőrzés szüneteltetése, szolgáltatásmegtagadás, távoli parancsvégrehajtás. Védekezés ellene: alkalmazás védelmének fejlesztésével, protokollverzió frissítéssel. Brute force Autentikáláshoz használják, ez az úgynevezett „nyers erő” támadási módszer. [8] Az adott karakter-intervallumon belül az összes lehetséges kombinációt kipróbáljuk a jelszó megszerzéséhez. A módszer előnye az, hogy előbb-utóbb biztosan megkapjuk az eredményt, a hátránya pedig, hogy ha rövid idő alatt akarunk célt elérni, óriási teljesítménnyel kell rendelkezzünk (nagy számítási kapacitású PC –vel, vagy botnettel) A védekezés ellene: adott időtartamon belüli próbálkozások maximális számát be kell állítani (például egy IP címről 10 másodperc alatt csak 3x lehessen próbálkozni). Szótáras jelszótörés Szintén egy jelszó megfejtésében segít. Kellően gyenge jelszavak esetén megesik, hogy értelmes kifejezéseket és/vagy számokat tartalmaznak, például neveket, évszámokat, egymás után következő számokat. (például: alma123, password1986, stb). Ezeket a sűrűn előforduló kifejezéseket úgynevezett szivárványszótárak alapján végig lehet próbálni. Előny: nagy valószínűséggel meg lehet szerezni a – könnyű megjegyezhetőség miatt használt - gyenge jelszavakat. Hátrány: erős jelszavak (például: P@5Sw0rD) megfejtésében nem segít. Védekezés a módszer ellen: erős jelszavak használatával sikeres lehet a védekezés. Social Engineering Emberi hiszékenységből vagy gondatlanságból származó, illegálisan megszerzett információk megszerzése (például jelszavak) és felhasználása. Azt is ebbe a kategóriába soroljuk, ha a támadó fél a nem publikus munkafolyamatok sorrendjéhez fér hozzá (ki, mit, mikor, mivel csinál).
- 11 -
3.4.3. Cél Talán szokatlan, de ésszerű csoportosítás lehet az is, hogy a támadó az eszközeit és módszereit milyen célból veti be: felderítés, illetéktelen jogosultságszerzés vagy a szolgáltatás megbénítása érdekében. Felderítés
Csomagfigyelő és analizáló programok (Packet sniffers)
ICMP scannelés (Ping sweep)
Port scannelés
Internetes információs adatbázisok (Internet information queries)
Csomagfigyelő és analizáló programok (Packet sniffers) Főleg hálózati forgalommal kapcsolatos anomáliáknál szokták felhasználni a sniffer szoftvereket (gyanús adatforgalom, sikertelen csatlakozási kísérletek, stb), illetve oktatásban.[3] Olykor viszont a protokollok gyengeségeiből fakadóan értékes információkhoz is juthatnak a támadók, mint például egy Telnet -es bejelentkezés esetén, ahol a felhasználónév és a jelszó titkosítatlan csatornán halad át, és a csomagok megfigyelésével könnyen meg is szerezhető. Ilyen szoftver például a Wireshark.[9]
5. ÁBRA: A WIRESHARK HASZNÁLAT KÖZBEN[9]
- 12 -
ICMP scannelés (Ping sweep) Napjainkban nem túlságosan megbízható technika, ugyanis a jelenlegi hálózati eszközök gyári beállításokkal is védekeznek már ellene. Lényege, hogy a támadó ICMP echo kérésekkel árasztja el az adott hálózati címtartományt, és ahonnan ICMP echo reply jön, azok aktív, működő hostok. Így felderíthető, hogy milyen eszközök találhatóak meg egy lokális hálózaton belül. Az fping program ebben nyújthat segítséget.[10] Port scannelés Léteznek olyan alkalmazások, amelyek felhasználásával kideríthető, hogy a célpontként megjelölt eszközön mely TCP illetve UDP portok vannak nyitva, továbbá azok „mögött” milyen alkalmazások figyelnek. Ezekből az adatokból, illetve az operációs rendszer típusából jó kiindulási ponthoz juthatnak a támadók, ugyanis a megszerzett információk
alapján
elkezdhetik
felkutatni
azon
sérülékenységet
kihasználó
programokat (exploit), amelyeket kifejezetten ezekhez az alkalmazásokhoz és verziókhoz írtak. Ilyen port scanner program például az Nmap.[11]
6. ÁBRA: PORT SCANNING: AZ NMAP HASZNÁLAT KÖZBEN[11]
- 13 -
Internetes információs adatbázisok Utoljára hagytam azokat az interneten található adatbázisokat, amik közvetlen segítséget általában nem nyújtanak a támadáshoz, ugyanakkor a kompetens támadók hasznos információkat nyerhetnek ki belőlük. Az egyik ilyen szolgáltatás a WHOIS [16], amellyel például a megadott domainről nyerhető ki minden publikus információ az ahhoz tartozó DNS rekordból (tulajdonos, szolgáltató, stb.). Hozzáférési támadás A hozzáférési támadások közös jellemzője az, hogy a támadó valamilyen módon el akarja nyerni a célpontnak jelölt eszköz bizalmát, és a jogosultságok megszerzése után adatokat akar megszerezni vagy manipulálni, illetve befolyásolni kívánja a rendszer működését. Ehhez mindenképpen szükséges az azonosítás (autentikáció) és a jogosultságok megszerzése (autorizáció); ez utóbbit az azonosítás után a rendszer biztosítja a támadó számára. Fontos továbbá, hogy a támadó fél számára nem is a jelszó az igazán fontos, hanem az abból számított úgynevezett hash érték, amit a jelszó alapján egyértelműen ki lehet számolni. Az a folyamat, mely során a hash előáll, egyirányú (a hash birtokában nem lehet visszaállítani a jelszót), ugyanakkor - mivel ez egy szűkebb halmazra való leképzést jelent - kulcsütközés léphet fel, tehát több jelszónak is lehet ugyanaz a hash értéke. Ebből fakadóan - elméletileg - elég, ha a támadó fél talál egy ugyanolyan karakterláncot, aminek a függvény ugyazt a hash kódot adja eredményül, és megszerzi a jogosultságot, de az adott hash érték megtalálására még így is kicsi az esély. Ennél vannak egyszerűbb módszerek is az illetéktelen hozzáférés megszerzésére, mégpedig a következők:
Nyers erő módszer (Brute force)
Trójai programok
IP cím hamisítás (IP Spoofing)
Csomagfigyelő és analizáló programok (Packet sniffers)
Bizalom elnyerése köztes eszköz segítségével (Trust exploitation)
Középső ember támadás (Man-in-the-middle)
- 14 -
Nyers erő módszer (Brute force) A korábbi fejezetben már volt szó róla, egy olyan támadási forma, ami a megadott karatker-intervallumokon belül (a..z, A..Z, 0..9, speciális karakterek) az összes lehetséges lehetőséget kipróbálja. Hatalmas számítási kapacitás szükséges ahhoz, ha belátható időn belül eredményt szeretnénk elérni. A számítási idő exponenciálisan nő a megszerezni kívánt karakterlánc hosszával. Sikeres jelszótörési módszer lehet, amennyiben a célponton nincsen beállítva olyan érték, amelyet nem érhetnek el sikertelen autentikációs kisérlettel adott idő alatt. Trójai programok Főként e-mailben terjedő trójai programok[12] lefuttatása esetén a támadó félnek esélye van átvenni a célpont feletti irányítást, rendszergazdai jogosultságokat megszerezni. Innentől fogva adminisztrátori jogkörrel cselekedhet az adott eszközön, adatokhoz férhet hozzá, sőt, a többi felhasználó adatait (jelszavakat, állományokat) is megszerezheti. Ez a veszély nem fenyegeti a legtöbb céget általában, hiszen annak dolgozói (és főleg az eszközök adminisztrátorai) folyamatos továbbképzésben vesznek részt, aminek köszönhetően elkerülhető a gyanús alkalmazások futtatása és terjesztése. A trójai programok segítségével továbbá botnetek alakíthatók ki, olyan hálózatok, amelyek a támadó fél akarata szerint akár DDoS[13] támadást is végrehajthatnak tetszőleges célpontok ellen. A probléma megelőzhető víruskereső szoftverek rendszeres használatával és frissítésével. IP cím hamisítás (IP Spoofing) Kellően gyenge védelemmel rendelkező eszközök esetén elképzelhető, hogy a támadó már azzal is megoldhatja az autentikációt és autorizációt, hogy meghamisítja a saját IP címét, mégpedig olyanná, amelyet a rendszer megbízhatónak tart. Természetesen ezt az információt előzőleg meg kellett szereznie a támadónak. Napjainkban önmagában ez a technika már nem elég egy sikeres támadás végrehajtásához, a legtöbb hálózaton ennél komplexebb autentikációra van szükség.
- 15 -
Bizalom elnyerése köztes eszköz segítségével (Trust exploitation) Az igen jól védett eszköz támadása helyett olyan eszközre hatol be a támadó, amelyben az eredetileg kiszemelt célpont megbízik, ezáltal könnyebben használhatja ki annak sérülékenyégeit. Ilyen eszköz lehet például egy DHCP szerver, alacsony védettséggel.
X 7. ÁBRA: TRUST EXPLOITATION TÁMADÁS
Középső ember támadás (Man-in-the-middle) A módszer lényege, hogy a támadó úgy avatkozik bele egy kommunikációba, hogy mindkét féllel elhiteti, hogy a partnerének küldenek üzeneteket, valamint a kapott csomagok is tőlük származnak. Ehhez a támadó meghamisítja azon csomagok forrását, amelyeket ő bocsát ki, és elkapja azokat, amiket az eredeti címzettnek küldtek.
8. ÁBRA: MAN-IN-THE-MIDDLE TÁMADÁS
- 16 -
Szolgáltatás megtagadásos támadás (DoS) A támadott fél (eszköz, hálózat, cég) kompromittálásának egyik leghatásosabb formája a szolgáltatásainak megbénítása. A szolgáltatás leállásából fakadóan közvetett és közvetlen anyagi és egyéb kárt is okozhat a támadás:
Közvetett módon: a felhasználók a számukra garantált elérhetőség (availability) hiányából fakadóan az SLA –ra (Service Level Agreement, Szolgáltatási Szint Megállapodás[14])
hivatkozva
kártérítési
igénnyel
és
a
szolgáltatás
lemondásával élhetnek, az adott vállalat hírneve is csorbulhat (ez szintén fontos része a kompromittálásnak)
Közvetlen módon: az aktuális üzleti folyamatok félbeszakadnak, a vészhelyzet megoldására erőforrást (munkaerőt, időt, pénzt, eszközöket) kell fordítani.
A szolgáltatás megtagadásos támadások (Denial of Service, DoS) osztályozása a csomagok számán és eredetén alapul. Ezek a következők: 1. Egy helyről egy csomag: A támadásban a támadó fél csak egy eszközt használ, és a célponton található sérülékenységek pontos ismerete alapján a szükséges eszköz segítségével képes olyan csomagot küldeni a webszerver számára, amely leblokkolhatja annak működését. Példa: Ping of Death: a támadó olyan csomagot küld a szervernek, aminek mérete nagyobb, mint amit az kezelni tud. A csomag a hálózaton több IP csomagra van felbontva, ennek szabványos méretét azok nem lépik át. A probléma a csomagok összeillesztésénél merül fel, ami a támadott fél eszközén történik. Az összeállított csomag méretéből adódóan puffer túlcsordulás történik, amitől megbénulhat az eszköz.
9. ÁBRA: DOS TÁMADÁS I.[13]
- 17 -
2. Egy helyről sok csomag Ez a támadási forma tekinthető az általános értelemben vett DoS támadásnak. A támadó fél a korábban tárgyalt módszerrel ellentétben a támadást a csomag minőségi jellemzője helyett azok mennyiségére alapozza. A sérülékenység ebben az esetben is a célpont memóriájának végességéből fakad, ugyanis ha egy eszköz adott idő alatt kevesebb adatot (esetünkben csomagot, kérést) képes kezelni, mint amennyit kap, véges időn belül (megfelelő védelmi intézkedések hiányában) működésképtelenné válik. Példa: TCP SYN flood: A támadás alapja a háromutas kézfogás módszerének ismerete. A támadó fél a célpont számára hamis forráscímmel rendelkező TCP SYN csomagokat küld, amire az TCP SYN+ACK csomaggal válaszol, de amíg erre nem kap olyan választ, amivel a TCP csatornát kialakíthatná, eltárolja azt a memóriában. Amint ez megtelik, nem lesz képes további TCP kapcsolatok kialakítására más irányból sem.
10. ÁBRA: DOS TÁMADÁS II.[13]
3. Sok helyről sok csomag (DDoS) Az elosztott szolgáltatás megtagadásos támadás (Distributed Denial of Service) napjainkban igen elterjedt támadási forma.[15] A különbség az előzőekben tárgyaltakhoz képest az, hogy a támadó fél nem csupán egy eszközt használ fel a forgalom generálására, hanem egy kiterjedt, átlagos számítógépekből kialakított hálózatot (botnetet). Ezen gépek tulajdonosai nincsenek tudatában annak, hogy az eszközeiket támadásokhoz használják fel, a támadó e-mailban terjedő féreg vagy trójai programok segítségével éri el az azok feletti irányítást. A módszer viszonylag egyszerűnek mondható: a megfertőzött számítógépek ICMP echo request (ping) csomagokat küldenek a célpontnak, az pedig a megnövekedett adatforgalmat nem képes kezelni.
- 18 -
Példa: MyDoom féreg[17], 2004. január végén terjedt el, február elsején 1 millió számítógép egyszerre kezdte meg a DDoS támadást az SCO Group hivatalos webszervere ellen. A domain egy időre elérhetetlenné vált, a támadás sikeres volt. Ezután nem sokkal újabb támadásokat indítottak a Microsoft és a RIAA (Recording Industry Association of America, Amerikai Hanglemezkiadók Szövetsége) ellen, majd hónapokkal később megbénították a Google cég kereső szolgáltatásának motorját és az AltaVista műkődésében is érezhető lassulás volt tapasztalható.
11. ÁBRA: DDOS TÁMADÁS
- 19 -
3.5. A kivédés lehetőségei Felderítő támadás ellen védekezhetünk erős jelszavak használatával[18], az adatok minél hatásosabb titkosításával, anti-sniffer eszközökkel, valamint IPS (Intrusion Prevention System, Támadás Megelőző Rendszer[19]) és tűzfal segítségével. Ez utóbbin gyárilag is megtalálhatóak olyan beállítások, amelyek felismerik, ha a támadó port scannelést hajt végre. A csomagfigyelő szoftverek ellen továbbá hatásos megoldás lehet a kapcsolt infrastruktúra (switched infrastructure) kiépítése, amely megnehezíti a két fél közötti információáramlás megfigyelését. Hozzáférési támadás ellen szigorú jelszó szabályzattal (policy) védekezhetünk, például a jelszó erősségének minimumát meghatározhatjuk a felhasznált karakter-intervallumok kibővítésével. Fontos a Trust exploitation támadás kivédéséhez az úgynevezett Principle of minimum trust gondolkodásmód kialakítása és alkalmazása, amely biztosítja, hogy kizárólag azok az eszközök bízzanak meg egymásban, amelyeknél ez igazán szükséges, és azok se teljes mértékben. A Man-in-the-middle támadás ellen a titkosítás továbbfejlesztésével lehet védekezni, pl. SSL és PGP technikák felhasználásával.[20] Mivel a legtöbb sikeres támadás a szoftverek felfedezett sérülékenységei miatt következhet be, létfontosságú a rendszer működése szempontjából az operációs rendszer és a többi alkalmazás biztonsági frissítéseinek telepítése és folyamatos karbantartása. DoS támadás ellen anti-spoofing technológiákat használhatunk fel, amik nagy arányban derítik fel az álcázás megtörténtét, IPS segítségével megelőzhető a szolgáltatás megbénítása, és sok esetben már az olcsóbb tűzfalak is képesek gyárilag a DoS támadás felismerésére. Amennyiben egy hálózaton belül létezik olyan adatforgalom, amelynél fontos a csomagok késési idejének minimalizálása, érdemes elgondolkozni a QoS (Quality of Service) bevezetésén. Ennek segítségével előtérbe hozható például a VoIP forgalmazás, ahol a csomagok késése érezhető változást okoz a telefonos beszélgetés során, míg az e-mailek kézbesítése általában alacsonyabb prioritással rendelkezik. Természetesen ezt teljes mértékben a saját igényekre lehet szabni, és elkerülhető a rendszer lassulása esetén a fontos adatforgalom akadályozása, kimaradása.
- 20 -
4. GYAKORLATI PÉLDA 4.1. A feladat bemutatása Szakdolgozatom elsődleges feladataként azt a célt tűztem ki, hogy egy tanácsadó cég szemszögéből mutassam be a sérülékenységvizsgálatnak, mint szolgáltatásnak a megvalósítását. Ennek érdekében segítséget kértem egy hazai információbiztonsági tanácsadó cég, a Proyet Kft. műszaki igazgatójától, aki a bemutatta a sérülékenységvizsgálati szolgáltatásuk folyamatát, az ajánlattételtől a feltárt sérülékenységeket tartalmazó dokumentáció átadásáig. A mérésben résztvevő hálózatot az egyik évfolyamtársam biztosítja, a webszerver elérhetősége: http://www.idphoto4you.com. A Proyet Kft. többféle módszert ajánl fel a megrendeléseik teljesítéséhez:
Az internet irányából az eszközök (kiszolgáló, hálózat) vizsgálatához a külföldi Qualys, Inc. szolgáltatását, a QualysGuard –ot veszik igénybe. Ez utóbbit fogom a következőkben részletesebben is bemutatni.
A megrendelő belső hálózatában elhelyezett, kifejezetten az ilyen jellegű mérésekre kifejlesztett készülékkel pontosabb információkhoz juthatunk, de ez kiszállást, több munkát és több időt igényel. Az eszköznek két Ethernet portja van, az egyik a mérni kívánt hálózatba kerül bekötésre (mérés), a másik segítségével pedig a WAN irányában kommunikál, a központtal tartja fent a kapcsolatot (vezérlés). Fontos, hogy a vizsgálni kívánt eszközök ugyanabban a VLAN -ban helyezkedjenek el. Ezen az eszközön szintén megtalálható a QualysGuard, mint szoftveres környezet.
A QualysGuard szolgáltatás két fő részből épül fel: 1. A méréseket lehetővé tevő mérőeszközök (akár egyedi) beállítása alapján elindítható vizsgálatsorozatok, és 2. Az a háttérben meghúzódó, jelen pillanatban megközelítőleg 10.000 sérülékenységet tartalmazó adatbázis. Ezek a sérülékenységek típusuk, súlyosságuk, kategóriájuk szerint csoportosítva vannak, valamint azok túlnyomó többségéhez ezek a bejegyzések megoldási javaslatokat is tartalmaznak. Úgy gondolom, ez a tudásbázis a szolgáltatás legértékesebb része.
- 21 -
12. ÁBRA: A QUALYSGUARD FELHASZNÁLÓI FELÜLETE
A cég által alkalmazott üzleti folyamat a következő lépésekből épül fel: 1. Kapcsolatfelvétel, konzultáció: A kapcsolatfelvétel kétféle módon történhet meg: vagy a megrendelő keresi fel közvetlenül a vállalatot, vagy pedig ez utóbbi tesz ajánlatot a leendő ügyfélnek. A valóságban az utóbbi a gyakoribb. Konzultációs alkalmakat a későbbiekben is lehet kérni a cég munkatársaitól, előzetes egyeztetés alapján. 2. Műszaki egyeztetés: Első lépésben titoktartási nyilatkozat aláírását vállalja a megbízott fél. A tanácsadó cég az ügyféllel letisztázza a műszaki részleteket a vizsgálat elvégzéséhez, mint például a vizsgálni kívánt eszközök típusa és száma vagy a mérés fajtája (külső vagy belső). A szerződésben foglalt készülékek száma az esetek túlnyomó többségében nagyságrendben n és n*10 (virtuális szerverek esetén a mérések számát az IP címek alapján határozzák meg, amelyekből egy fizikai eszközön többet is lehet találni. Ezek külön eszközöknek számítanak a vizsgálat szempontjából). Ezeken felül általában az IT osztály vezetőjének, illetve kis vállalatok esetén a cég adminisztrátorának a munkaállomása is beletartozik a vizsgálatba.
- 22 -
3. Jelentés elkészítése: A vizsgálat ebben a szakaszban történik meg, ahogy a kapott eredmények alapján történő dokumentáció elkészítése is. Többféle jelentésről (Report) beszélhetünk egy mérés elvégzése után, attól függően, hogy kinek készül: a. Az IT osztály (biztonsági csoport, stb.) számára készült jelentésben minden rendelkezésre álló részlet szerepel a hibák minél hamarabbi kijavítása érdekében, megoldási javaslatokkal, pontos adatokkal, b. A vezetőség számára látványos, gyorsan átlátható jelentés a mérés eredményességét és szükségességét mutatja be, a lehető legkevesebb informatikai szakkifejezés használata mellett az érthetőség érdekében. 4. Összefoglaló előadás A tanácsadó cég vállalja, hogy a megbízó fél vezetősége előtt prezentálja a vizsgálat során tapasztalt hiányosságokat. 5. A vizsgálat esetleges megismétlése Amennyiben arra igény van, a vizsgálatokat adott időközönként végrehajtva rendszeresíteni is lehet, így lehetőség van arra, hogy megfigyelhessenek egyfajta tendenciát az informatikai biztonsággal kapcsolatban. A rendszeres vizsgálat segít minél hamarabb kiszűrni például egy adott szoftver frissítése, vagy éppen annak hiánya okán kialakuló biztonsági rések jelenlétét, de mindenesetre minimalizálja a kompromittálás lehetőségét és annak bekövetkezése esetén az okozott kár nagyságát. Bár a többszöri mérés lehetősége csak opcionális, ugyanakkor erősen ajánlott az ügyfelek számára.
Fontosnak tartom megjegyezni, hogy az Ethical hacking csupán a hibák felfedezésére és dokumentálására irányul, a javítás minden esetben a helyi adminisztrátor, vagy az ebben illetékes csoport (biztonsági csoport, IT, stb.) feladata és kötelessége. Külön kérésre konzultációs időpontot lehet a tanácsadó céggel egyeztetni, ekkor személyes véleményezést adhatnak a legfontosabbnak tűnő sérülékenységekről.
- 23 -
A szolgáltatás folyamata során a szükséges dokumentumok az alábbiak lehetnek: 1. Titoktartási nyilatkozat: Mindkét fél számára fontos a bizalom, és annak jogi hátterének kialakítása a későbbi félreértések elkerülése érdekében. 2. Szerződés: A felhatalmazás (és annak részletei) a vizsgálatok elvégzésére Penetration test, azaz behatolásvizsgálat esetén külön figyelmeztetni kell a megrendelőt a későbbi jogi incidensek elkerülése miatt, és ennek érdekében abba írásban bele kell egyezniük. 3. Hálózati dokumentáció bekérése: Szerverek, gépek, portok, tehát informatikai vagyonelemek és azok aktuális beállításai. Mivel sűrűn változhatnak (például a portok vagy az IP címek), ezért általában nincs frissen tartva. Ritkán található hálózati dokumentáció egy cégnél, ha mégis lenne, akkor azt valószínűleg még a szolgáltatójuk adhatta a hálózat kiépítésekor, ők viszont csak a saját felszerelésükről tudtak adni dokumentációt, más készülékekről nem) 4. Dokumentáció: Az eredmény birtokában és annak felhasználásával különböző jelentések, és azok mellé szubjektív véleményezés csatolása a hálózat állapotáról, valamint a legsürgősebbnek tűnő teendőkről. A
mellékletben
megtalálható
a
Hozzájárulás
sérülékenységi
vizsgálathoz
c.
dokumentum, a további dokumentumok a szakdolgozat CD mellékletére kerültek rá. A szolgáltatást kínáló cég mindig törekszik arra, hogy független szakértőként állhassanak rendelkezésre. Amennyiben nem független szakértőre bíznák a vizsgálat végrehajtását, az biztonsági kockázatokkal járhat (rossz esetben például a cég adminisztrátora akár el is hallgathatja azokat a réseket, amelyek kiküszöbölése meghaladja a szakmai tudását, ezáltal lehetőséget nyújt a sikeres támadásra a rendszer ellen).
- 24 -
4.2. A szolgáltatás bemutatása a gyakorlatban Előzetes konzultációkon vettem részt a dolgozatomban segítséget nyújtó Proyet Kft. műszaki igazgatójával, aki segített kiválasztani a feladatban meghatározott hálózati eszköz vizsgálatához optimális mérési módszert, továbbá az időközben felmerült kérdéseimre rövid időn belül teljes mértékben kielégítő válasszal tudott szolgálni. Konzultáció, műszaki egyeztetés A megrendelővel több konzultációt is tartottam, miután korábban megbizonyosodtam ingyenesen elérhető szolgáltatások segítségével a tulajdonjogokról és néhány mellékes további információról (szolgáltató, stb.), ilyen szolgáltatás például a WHOIS.[16] Az előzetes felmérés a későbbi bonyodalmak (adott esetben perek) elkerülése érdekében szükséges. A műszaki egyeztetésen a titoktartási nyilatkozat aláírása után megismerkedtem a vizsgálni kívánt hálózat topológiájával, valamint a hálózati eszközök tulajdonságaival. A titoktartási nyilatkozatnak része, hogy a szakdolgozatban felhasználhatom a hálózatról begyűjtött részleteket és az eredményeket, de semmilyen más formában nem adhatom tovább azokat. Jelentés elkészítése (mérés) Arra a megállapításra jutottam, hogy a vizsgálni kívánt hálózatot legeredményesebben a QualysGuard webes felületű szolgáltatásával tudjuk megmérni. A kapott eredményeket HTML és PDF formátumban a megrendelő részére át fogom adni (további lehetőségként megemlítettem a hivatalos kimutatási formát is, amely a Mellékletek/Dokumentumok/Pelda_Report.doc állományban található a szakdolgozat CD mellékletén, de ezt a megrendelő nem igényelte). Javítás, a vizsgálat megismétlése Amennyiben a felfedezett sérülékenységeket a megrendelő segítségével képesek leszünk kijavítani, az eszközön új mérést fogok elvégezni, hogy megbizonyosodjak a mérési eredmény pontosságáról és a szolgáltatásom eredményességéről.
- 25 -
4.2.1. A vizsgált hálózat bemutatása Ebben a fejezetben a mérni kívánt webszerver hálózati topológiáját, szoftveres és hardveres jellemzőit, továbbá néhány beállítását (IP és MAC cím) fogom bemutatni.
Logikai topológia
A webszerveren kívül a helyi hálózat része még egy munkaállomás, továbbá egy forgalomirányító. A hálózat logikai topológiája a 13. ábrán látható.
78.139.2.2
Si
Router DLink DI-604 192.168.0.1
Workstation MUSZK 192.168.0.149
Server IDSERVER 192.168.0.151
13. ÁBRA: A VIZSGÁLT HÁLÓZAT LOGIKAI TOPOLÓGIÁJA
Az eszközök jellemzése
Az eszközökön megtalálható főbb alkalmazások (operációs rendszer, firmware, stb): Router (Router):
Firmware version: V3.15, Fri, Apr 21 2006
Workstation (MUSZK):
Microsoft Windows XP Professional SP3, COMODO Internet Security 3.14.130099.587
Server (IDSERVER):
Microsoft Windows XP Professional SP3, COMODO Firewall 3.13.126709.581, Apache HTTP Server 2.2, PHP 5.2.9-2
- 26 -
A MUSZK nevű munkaállomás bemutatása:
A gép egy általános célú munkaállomás. Több operációs rendszer közül is választhatunk a boot folyamat közben. Az IDSERVER kiszolgáló leállása esetén a MUSZK munkaállomás képes átvenni annak szerepét, így a redundancia megjelenik a hálózaton. A MUSZK-ot ehhez újra kell indítani, majd a megfelelő operációs rendszer elindítása esetén automatikusan betöltődik a webszolgáltatáshoz szükséges szerveralkalmazás.
Az IDSERVER nevű kiszolgáló (server) bemutatása:
A mérés elsődleges célpontja a hálózaton megtalálható kiszolgáló, az IDSERVER. A webalkalmazás ideális esetben ezen az eszközön fut. Apache webszerver és MySQL adatbáziskezelő szerver van telepítve rá, PHP motor, valamint a webalkalmazáshoz szükséges Microsoft Windows XP operációs rendszer.[21][22][23][24] Az IDSERVER részletes hardveres és szoftveres jellemzői:
Processzor:
Intel Pentium 4, 2533 MHz (14 x 181)
Rendszermemória:
1536 MB (DDR SDRAM)
Hálózati kártya:
Intel(R) PRO/1000 CT Network Connection
Operációs rendszer:
Microsoft Windows XP Professional SP3
PHP motor:
PHP 5.2.9-2
Webszerver:
Apache HTTP Server 2.2
Tűzfal:
COMODO Firewall 3.13.126709.581
A webszerver statikus (fix) IP címmel rendelkezik, elérhető a 78.139.2.2 címen: Pinging 78.139.2.2 with 32 bytes of data: Reply from 78.139.2.2: bytes=32 time=11ms TTL=55 Reply from 78.139.2.2: bytes=32 time=9ms TTL=55 Reply from 78.139.2.2: bytes=32 time=10ms TTL=55 Reply from 78.139.2.2: bytes=32 time=10ms TTL=55 Ping statistics for 78.139.2.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 9ms, Maximum = 11ms, Average = 10ms
- 27 -
4.2.2. Mérések előkészítése A vizsgálatok során négy különböző mérést hajtok végre a rendszeren: Alkalom
TCP beállítások
UDP beállítások
1. mérés
Standard TCP
Standard UDP
2. mérés
Light TCP
Standard UDP
3. mérés
Standard TCP
Light UDP
4. mérés
Light TCP
Light UDP
14. ÁBRA: A MÉRÉSEK TULAJDONSÁGAI
A Standard és a Light közötti különbség főként a vizsgálatban résztvevő portok számára vonatkozik. Mindkét esetben lehetőségünk van (a megrendelő külön kérésére, illetve a saját feladatunk megkönnyítése érdekében) az eredetileg meghatározott portok halmazát kiegészíteni saját kezűleg megadott portokkal vagy porttartománnyal. A TCP és az UDP protokoll közötti alapvető különbségekből adódóan felmerül a mérés futásidejének kérdése is. A TCP protokoll használatakor a két végpont között szinkronizációs folyamat – háromutas kézfogás – történik meg, és annak meghatározott időn belül létre kell jönnie, vagy a kapcsolat létrehozására irányuló törekvés megszakad. Az UDP protokoll esetében szinkronizációról nem beszélünk, tehát itt minden esetben meg kell várnunk a timeout –ot, ha egy portot akarunk megszólítani. Ez akkor jelenthet problémát, ha viszonylag sok UDP portot vizsgálunk meg a teszt során. A tanácsadó cég műszaki igazgatójának tapasztalatai szerint nem történt még olyan vizsgálat az eddigi megrendeléseik során, ahol ne találtak volna sérülékenységet, amennyiben ez történne, az gyanúra adhat okot, például, hogy rossz beállításokkal indítottuk el a vizsgálatokat. Ez a valóságban a hibás (vagy csak részleges) dokumentáció, illetve a kellő mennyiségű segítségnyújtás hiánya miatt történhet meg. Az alábbiakban bemutatom a beállítási profil elkészítését lehetővé tevő menüpontot.
- 28 -
Beállítási profilok létrehozása és alkalmazása A QualysGuard szolgáltatás részeként lehetőségünk nyílik létrehozni saját beállítási profilokat. Ésszerű megoldás lehet arra az esetre, ha több (vagy adott esetben sok) hasonló jellegű mérést kell elvégezni a megrendelések során, amelyek nagyjából azonos beállításokat igényelnek. Természetesen létezik egy alapbeállítás (default), amelyet a rendszeren belül Initial Options –nek van elnevezve. Egy saját beállítási profil elkészítésénél első pillantásra nem találunk sok beállítási lehetőséget, viszont az Advanced gombra kattintva lehetőséget kapunk a beállítások finomhangolására is. Amennyiben vissza szeretnénk térni az előző állapotba, a Basic gombra kell kattintanunk.
15. ÁBRA: OPTION PROFILE
A beállítási profil elkészítéséhez három kategóriába vannak osztva azok a tulajdonságok, amikkel a mérést paraméterezhetjük: Scan, Map, Additional. Ha jobban megfigyeljük a Basic és az Advanced mód közötti különbséget, akkor azt az összefüggést tapasztaljuk, hogy a Basic módban beállítható értékek mindegyikét megtaláljuk az Advanced módban is. Az alábbi képeken kiemeléssel jelzem azokat a beviteli és információs mezőket, amelyek a Basic módban is megtalálhatóak.
- 29 -
16. ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: SCAN
- 30 -
A Scan kategóriában található meg a legtöbb olyan beviteli mező, amely értékeinek megváltoztatására szükségem lehet a feladat elvégzése érdekében. Ezek közül is a legfontosabb a portok beállítása (Ports), ahol a vizsgált TCP és az UDP portok halmazát lehet szűkíteni illetve bővíteni. A None lehetőség kiválasztásával teljes mértékben ki lehet hagyni az adott protokollokat, a Full –lal pedig az összes adott protokollhoz tartozó portot megvizsgálhatjuk (ez drasztikusan megnövelheti a mérés futásidejét). Az Additional mező kiválasztásával, kézzel is hozzáadhatunk portokat a korábban megjelölt intervallumhoz.
17. ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: MAP
A Map kategóriában meghatározott értékek alapján fogja a vizsgálat adatokkal feltölteni az eredményben az összegyűjtött információk (Information Gathered) csoportot (később kifejtve). Tapasztalataim szerint az alapbeállításban megtalálható értékek megfelelnek az általános célú felhasználásra, azokon a jelenlegi feladat elvégzéséhez nem kellett változtatni.
- 31 -
18. ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: ADDITIONAL
Az Additional kategóriában további beállításokat hajthatunk végre a mérésünkre főként a host -okra - vonatkozóan, továbbá olyan eszközöket adhatunk meg, amelyeket szeretnénk kihagyni a vizsgált tartományból. A feladat elvégzésekor ezek átállítására nem volt szükségem, így meghagytam az alapbeállításokat. A beállítási profilokat a méréseim során főként a vizsgált TCP és UDP portok száma alapján állítottam át, ennek megfelelően kapták a nevüket:
default: Standard TCP és Standard UDP
idphoto4you_2_TCP_Light: Light TCP és Standard UDP
idphoto4you_3_UDP_Light: Standard TCP és Light UDP
idphoto4you_4_TCP_UDP_Light: Light TCP és Light UDP
- 32 -
4.2.3. Első mérés Az előkészületek után megkezdem a sérülékenységvizsgálat kulcsfontosságú részét, a méréseket. Első alkalommal azt a beállítási profilt használom, amit a szolgáltatás eredetileg beépítve tartalmaz (default, Standard TCP és Standard UDP). A mérés elindításakor három adatot kell megadni: a mérés nevét (Title), a beállítási profilt (ezt egy legördülő listából választhatjuk ki), továbbá a vizsgált IP címtartományt. Az elvárásaim az első méréssel szemben: fedezzük fel a teszt segítségével a sérülékenységek számát, típusait és súlyosságukat, és ezeket egyértelműen meg lehessen állapítani az eredményül kapott riportból. Az így kinyert adatokat a későbbi hibajavításhoz fel szeretném használni, ezért is fontos, hogy minél informatívabbak legyenek. Mivel nincs még semmilyen tapasztalatom a szolgáltatással kapcsolatban, ezért a vizsgálat időtartamáról sincs elképzelésem. Egy meglehetősen komplex teszt-sorozatról van szó, ezért valószínűnek tartom, hogy nem kapok perceken belül jelentést a mérés befejeződéséről. A vizsgált portok száma alapján ettől a méréstől várom a legnagyobb mérési időt, ugyanakkor a legrészletesebb és legpontosabb eredményt is.
19. ÁBRA: ELSŐ MÉRÉS BEÁLLÍTÁSA
- 33 -
20. ÁBRA: ELSŐ MÉRÉS FUTÁS KÖZBEN
21. ÁBRA: ELSŐ MÉRÉS ÖSSZEGZÉSE
A mérés futásideje körülbelül 45 perc volt. Ennél kevesebbre számítottam, de valószínűleg a többi mérés sem fog tovább tartani. Az összegzés (Vulnerability Summary) csak minimális információt tartalmaz a kapott eredményről, annak részletes bemutatását és kiértékelését később teszem meg.
- 34 -
4.2.4. Második mérés Ebben a mérésben már felhasználhattam a korábban említett New Option Profile menüpontban létrehozott beállítási profilt is, aminek az idphoto4you_2_TCP_Light nevet adtam. A későbbi mérésekre való tekintettel célszerűnek láttam az egyértelmű elnevezést, és ennek megfelelően adtam ugyanezt a nevet a második mérésnek is. A további mérések során is ezt az elvet fogom követni az elnevezések tekintetében. Az előző méréshez képest mindenképpen rövidebb futásidőre számítok, ugyanakkor nagyságrendi különbséget az UDP portok számának azonossága miatt nem várhatok el a korábban említett okok miatt (timeout). A megtalált sérülékenységek számát figyelembevéve semmiképpen sem kaphatok nagyobb értékeket az előző mérésnél. Ez csak két módon történhetne meg: ha az aktuális mérés mélyrehatóbb vizsgálatot eredményezne (ez egyértelműen kizárható), illetve ha a vizsgált eszközön más feltételek között indítanám el a mérést, például, régebbi verziójú PHP motor, rosszul beállított tűzfal, vagy olyan operációs rendszer használata, amelyet nem frissítenek rendszeresen. Mivel a mérések között semmilyen változtatást nem okoztunk a szerveren, ezért ezt az esetet is kizárhatjuk. Sejteni lehet, hogy a későbbi hibajavítás során ez a mérés kevésbé fog szerepet játszani.
22. ÁBRA: MÁSODIK MÉRÉS BEÁLLÍTÁSA
- 35 -
23. ÁBRA: MÁSODIK MÉRÉS FUTÁS KÖZBEN
24. ÁBRA: MÁSODIK MÉRÉS ÖSSZEGZÉSE
A mérés befejeződése több érdekességgel is szolgált. A hibajavításban irreleváns, mégis meglepett, hogy nagyságrendben ugyanannyi ideig tartott a mérés, mint az első esetben (44 perc). Ennél sokkal érdekesebb a megtalált sérülékenységek és információk száma, ami pontosan ugyanannyi volt, mint az előző mérés során. Látszólag tehát az első két mérés eredménye semmiben sem különbözik egymástól.
- 36 -
4.2.5. Harmadik mérés Ehhez a méréshez is új beállítási profilt hoztam létre idphoto4you_3_UDP_Light névvel, ez Standard TCP és Light UDP beállításokat tartalmaz. Az elnevezési konvenciókat az előző mérésnél fejtettem ki. A korábbi mérésekhez képest futásidőben jóval kevesebbet várok el, a megszerzett sérülékenységek listájával és a begyűjtött információval kapcsolatban nagyságrendi különbséget érzésem szerint nem fogok tapasztalni. A szerveren futó tűzfalon valószínűleg nagyon kevés UDP port van nyitva, ebből fakadóan valószínűleg egyik mérés során sem fogok tapasztalni ezzel kapcsolatos sérülékenységeket. Mivel ezúttal sem változtattunk semmit a szerveren, ami a védelmet befolyásolhatná, ezért több sérülékenységet most sem tapasztalhatunk az első méréshez képest.
25. ÁBRA: HARMADIK MÉRÉS BEÁLLÍTÁSA
- 37 -
26. ÁBRA: HARMADIK MÉRÉS FUTÁS KÖZBEN
27. ÁBRA: HARMADIK MÉRÉS ÖSSZEGZÉSE
Ettől a méréstől vártam a futásidő drasztikus csökkenését leginkább, de ezúttal is körülbelül 45 perc volt az időtartam. Ebből azt a következtetést vontam le, hogy ezt az időmennyiséget elsősorban nem a mérési feltételek befolyásolják. A sérülékenységek száma ezúttal is megegyezik az előző mérések eredményével.
- 38 -
4.2.6. Negyedik mérés Elméletileg az utolsó méréstől várható a legkevesebb értékes információ, hiszen az idphoto4you_4_TCP_UDP_Light beállítás szűkíti le leginkább a vizsgált portok halmazát. Az előző mérések eredményeit megfigyelve ugyanakkor belátható, hogy nincs különbség esetünkben a Standard és Light TCP, illetve a Standard és Light UDP beállítások során tapasztalt eredmények között, és ez akkor sem változhat, ha a két Light beállítást kombináljuk. Az első mérésem elkezdése előtt úgy gondoltam, hogy ez a mérés fog a legrövidebb ideig tartani, de az előző három mérésből kiindulva ebben is elkezdtem kételkedni. További lehetőségként be lehetne állítani a New Option Profile menüpontban a portok halmazának manuális bővítését, de ezt általában akkor célszerű megtenni, ha a megrendelő ezt kifejezetten kéri, illetve valamilyen információ áll a rendelkezésünkre arról, hogy bizonyos szolgáltatások milyen portokon futnak az adott eszközön. Jelen esetben nem történt ilyen kérés, ezért ettől eltekintünk a mérések során.
28. ÁBRA: NEGYEDIK MÉRÉS BEÁLLÍTÁSA
- 39 -
29. ÁBRA: NEGYEDIK MÉRÉS FUTÁS KÖZBEN
30. ÁBRA: NEGYEDIK MÉRÉS ÖSSZEGZÉSE
A korábbi mérések alapján a jelenlegi vizsgálat semmi újjal nem szolgált, az időtartam is megközelítőleg ugyanakkora volt, és a megtalált sérülékenységek száma is azonos a korábbi eredményekkel. Mivel számomra a négyféle beállítás gyakorlatilag ugyanazt az eredményt hozta ugyanannyi idő alatt, elgondolkoztam rajta, nem rontottam-e el valamit a beállításoknál? Utólag is leellenőrizve, mindent jól csináltam. A következő konzultáció során meg fogom kérdezni a konzulensemet ezzel kapcsolatban.
- 40 -
4.2.7. Kiértékelés Miután a mérések eredményeit összehasonlítottam egymással, a várakozásaimnak ellenmondó következtetést kellett levonjak. Mint kiderült, mind a négy mérés ugyanazt az eredményt adta, másképpen fogalmazva a negyedik – legdurvább szemcsézettségű – mérés által biztosított adatoknál többet a komplexebb mérések sem tudtak nyújtani. A konzultáció során megtudtam, hogy a legtöbb esetben a vizsgált eszköz illetve hálózat sérülékenységéhez elegendő a Light TCP és Light UDP beállítások használata. A mérések eredményei között például akkor lehet különbség, ha úgynevezett egzotikus portok vannak használatban (például 9xxx –es porton fut egy bizonyos szolgáltatás), ezt a Light TCP illetve Light UDP beállítású mérés nem feltétlenül találná meg. Amennyiben használatban van ilyen port az eszközön, azzal általában a megrendelő is tisztában van, és ennek az információnak az átadásával segítheti az együttműködést. A beállítási profiloknál ezeket a portokat kézzel is hozzá lehet adni, amennyiben az nem szerepel a listában. A mérési eredmény dokumentuma több részre osztható fel: A dokumentum fejlécében megtalálható a mérés dátuma mellett annak a személynek az adatai is (név, felhasználónév, beosztás, elérhetőségek), aki azt elvégezte. Ez abban az esetben lehet igazán értékes információ, amikor az adott eszköz (hálózat) vizsgálata egy csapatnak (project team) van kijelölve. A dokumentum törzsében található meg a jelentés összegzése (Report Summary), a sérülékenységek összegzése (Summary of Vulnerabilities), azok táblázatos formában megadott eloszlása a súlyosságuk és típusuk, valamint kategóriájuk szerint, végül azok részletes kifejtése (Detailed Results). A Report Summary rovat tartalmazza azokat az adatokat, amelyek a hálózatot és magát a mérést jellemzik, többek között a vizsgált hostok számát, az IP címek tartományát, a mérés típusát, állapotát, a mérőeszköz azonosítóját, és azt a beállítási profilt, amellyel a vizsgálat elindult. A sérülékenységek összegzése (Summary of Vulnerabilities) két értéket foglal magába: a felfedezett (valós vagy vélt, a továbbiakban: igazolt illetve potenciális) sérülékenységek és megszerzett információk (később kifejtve) összegét, illetve a biztonsági kockázat nagyságát (Security Risk (Avg)). Itt jegyezném meg, hogy ez
- 41 -
utóbbi kifejezés félreérthető, a mérés eredményeinek áttekintése után felvettem a kapcsolatot a konzulenssel, aki a kérdésemre felvilágosított, hogy ez az érték a legsúlyosabb (később kifejtve) sérülékenység nagysága, nem pedig azok átlaga. A sérülékenységek csoportosítása elsőre számomra nem volt egyértelmű, ezért az alábbi ábrán érthetőbb módon mutatom be azok osztályozását a szolgáltatás szemszögéből: Összes sérülékenység (Summary of Vulnerabilities)
Összegyűjtött információk (Information Gathered)
Sérülékenységek (Vulnerabilities)
Igazolt sérülékenységek (Vulnerabilities) Ezek
alapján
három
Potenciális sérülékenységek (Potential Vulnerabilities) fő
csoportról
beszélhetünk:
igazolt
és
potenciális
sérülékenységekről, illetve megszerezhető információkról
Igazolt sérülékenységek (Vulnerabilities): Olyan biztonsági rések az adott eszközön, amely valós fenyegetést jelent, és befoltozásaik elsődleges fontosságúak az informatikai biztonság szempontjából.
Potenciális sérülékenységek (Potential Vulnerabilities): Veszélyek, amelyeket a mérőeszköz nem tudott bizonyítani, de a létezése valószínű. Olyan esetekben fordulhat ilyen elő, ha egy eszköz elméletileg képes lenne álcázni bizonyos jellemzőit.
Összegyűjtött információk (Information Gathered): Olyan publikus adatok az adott eszközről, amelyet a támadó felhasználhat a saját céljainak eléréséhez. Ezek egy része viszonylag ritkán használható fel (például: van tűzfal az eszközön), de akadnak olyanok is, amelyek elősegíthetnek egy sikeres DoS támadást (például ICMP Echo requestre válaszol, stb), vagy a támadó megtalálhatja a webhely korábbi változatát a publikus könyvtárstruktúrában, amennyiben annak elfedésére nem történt erőfeszítés.
- 42 -
Amint a bevezetőmben már említettem, feltörhetetlen rendszer nem létezik, sérülékenységek mindig akadnak. Korábban említettem azt is, hogy amennyiben a vagyonelem
(esetünkben:
webszerver)
értéke
adott,
a
kockázat
a
veszély
bekövetkezésével egyenesen arányos. Ezért is fontos az, hogy a sérülékenységeket súlyosságuk alapján kategorizálhassuk. Ezt a QualysGuard megteszi helyettünk. Az igazolt és a potenciális sérülékenységeket 1-5-ig, az összegyűjtött információkat pedig 1-3-ig terjedő skálán sorolják be a veszélyességük alapján az alábbi táblázat szerint: Igazolt
Potenciális
Összegyűjtött
sérülékenységek
sérülékenységek
információk
■□□□□
Elhanyagolható
Elhanyagolható
Elhanyagolható
■■□□□
Könnyű
Könnyű
Közepes
■■■□□
Közepes
Közepes
Fontos
■■■■□
Súlyos
Súlyos
-
■■■■■
Extrém
Extrém
-
Összességében elmondható, hogy igazolt és potenciális sérülékenységek esetén a 4-5-ös besorolásúakat sürgősen ki kell javítani, a 3 –asat „illik”, tehát ha van rá kapacitás, akkor foglalkozni kell velük. Az 1-2 –es súlyosságú sérülékenységeket csak a profi hackerek képesek kihasználni, ezekhez ugyanis komolyabb tudás és eszköz szükséges. Összegyűjtött információk esetén csak a kettes és hármas súlyosságúakkal célszerű foglalkozni, az előbb említett okokból kifolyólag. A mérések során az alábbi sérülékenységeket találtam a rendszerben: Igazolt sérülékenységek:
Specific CGI Cross-Site Scripting Vulnerability
Web Server HTTP
Trace/Track Method Support
Cross-Site Tracing
Vulnerability
Expose_php Set to On in php.ini
Apache Web Server ETag Header Information Disclosure Weakness
- 43 -
Potenciális sérülékenységek:
Session-Fixation Social Engineered Session Hijacking
PHP cURL "safe_mode" and "open_basedir" Restriction Bypass Vulnerability
PHP "exif_read_data()" Denial of Service Vulnerability
PHP Versions Prior to 5.3.1 Multiple Vulnerabilities
PHP Versions Prior to 5.2.13 Multiple Vulnerabilities
Összegyűjtött információk:
Web Server Version
Traceroute
Firewall Detected
DNS Host Name
Internet Service Provider
List of Web Directories
Default Web Page
Open TCP Services List
Host Names Found
ICMP Replies Received
Host Responds to TCP SYN Packet with Other Flags On with SYN ACK
IP ID Values Randomness
Degree of Randomness of TCP Initial Sequence Numbers
Operating System Detected
HTTP method TRACE and/or TRACK Enabled
Host Scan Time
A továbbiakban a felsorolt sérülékenységek és megszerzett információk közül bemutatok néhányat, azok kijavítására megoldási javaslatokat is teszek.
- 44 -
Néhány sérülékenység bemutatása A korábban felsorolt vélt vagy valós sérülékenységek közül az alábbiakat mutatom be:
Specific CGI Cross-Site Scripting Vulnerability (igazolt)
Session-Fixation Social Engineered Session Hijacking (potenciális)
PHP Versions Prior to 5.2.13 (5.3.1) Multiple Vulnerabilities (potenciális)
Specific CGI Cross-Site Scripting Vulnerability (igazolt) A Cross-Site Scripting (rövidítve: XSS) kifejezés egy olyan módszerre utal, ahol a támadó fél általában egy weblap felületén található szövegbeviteli mezőben olyan karaktersorozatot (string) ír be, amely kellő védelem hiányában a szerveren található adatokat megjelenítheti (SQL injection) vagy annak a személyes információit érheti el, aki a weblapot látogatja. Ez utóbbit javascript beágyazásával teheti meg, aminek alapjait most fogom bemutatni a vizsgált webszerver segítségével. A sikeres kísérlethez mindössze a böngészőalkalmazás címsorában található URL-t kell kibővítenünk, például
a
31.
ábrán
látható
állapotot
kapjuk
eredményül,
ha
beírjuk
www.idphoto4you/index.php/123?Lang="><script>alert(document.domain) karakterláncot a címsorba:
31. ÁBRA: A CROSS-SITE SCRIPTING SÉRÜLÉKENYSÉG BEMUTATÁSA
a
- 45 -
Session-Fixation Social Engineered Session Hijacking (potenciális) A weboldalak látogatása esetén az aloldalak közötti navigálás közben az adataink továbbítását (például egy bejelentkezés után) az úgynevezett munkamenet (session) segítségével oldják meg. Ezeknek a munkameneteknek véletlenszám-generátorral meghatározott azonosítóik vannak (Session ID), amellyel azokat meg lehet egymástól különböztetni. A mérőeszköz segítségével arra a következtetésre jutottam, hogy lehetséges olyan explicit értékadás, amellyel adott azonosítójú munkamenet indítható el a vizsgált webszerveren. Ezt például olyankor használhatja fel a támadó fél, ha az így létrehozott URL használatára veszi rá a gyanútlan felhasználókat (emiatt szerepel a sérülékenység nevében a Social Engineered kifejezés), és miután befejezték a saját munkamenetüket, a támadó a munkamenet azonosító birtokában további műveleteket is végrehajthat a felhasználó jogosultságaival. Az ehhez tartozó URL a következő: http://idphoto4you.com/?PHPSESSID=0123456789abcdef0123456789abcdef.
PHP Versions Prior to 5.2.13 (5.3.1) Multiple Vulnerabilities (potenciális) Mint minden alkalmazás, a webszerveren futó PHP motor is tartalmaz kihasználható biztonsági réseket. Az alkalmazások fejlesztői folyamatosan adnak ki frissítéseket a szoftverükhöz, amelyben a fejlesztések mellett a felfedezett biztonsági hiányosságokat is igyekeznek csökkenteni. Ezért létfontosságú tehát, hogy az operációs rendszert, valamint lehetőleg az összes többi alkalmazást is naprakészen tartsuk azok legfrissebb stabil verzióinak megszerzésével. Ennek hiányát jelzi a szóban forgó sérülékenység. Azért nem lehet bizonyítani ezt a veszélyt, mert a webszerverek képesek arra, hogy bizonyos adatokat elrejtsenek vagy megváltoztassanak a külső fél számára, így például azt is elhitetheti a támadóval, hogy egy korábbi verziót használ, miközben a legfrisebb van telepítve. Ezt az adatrejtő technikát használhatják fel például az úgynevezett mézesbödön (honeypot) szervereken, amelyek a támadó részére látszólag könnyű célpontot nyújtanak, ugyanakkor csak naplózó és behatolásfigyelő funkciója van, semmilyen fontosabb szolgáltatás, sem adat nem található meg rajta.
- 46 -
4.2.8. A sérülékenységek kijavítása és a megismételt mérés bemutatása Ebben a fejezetben a korábban bemutatott négy sérülékenység kijavításának menetetét tervezem bemutatni. Miután a javítások megtörténtek, új mérést fogok végrehajtani, hogy bebizonyítsam a sérülékenységvizsgálat által feltárt biztonsági rések számának csökkenését, ezáltal a rendszer állapotának jelentős javulását. Specific CGI Cross-Site Scripting Vulnerability A felfedezett Cross-Site Scripting sebezhetőség alapja a böngésző címsorában megfigyelhető Lang paraméter értékének módosításával előidézhető javascript programkód lefuttatása.[2] Ezt úgy tudjuk megakadályozni, hogy a paraméter értékét annak feldolgozása előtt megvizsgáljuk, és a tartalom alapján folytatjuk a HTML oldal generálását. Az ellenőrzést a PHP programban kell elvégezni, ami a fejlesztők feladata. Session-Fixation Social Engineered Session Hijacking A sérülékenységet abban az esetben használhatja ki a támadó, ha a böngésző címsorában explicit módon rendel a munkamenet-azonosítóhoz (Session ID) értéket. Ha ezt a veszélyt meg szeretnénk előzni, a webszerveren megtalálható php.ini konfigurációs állományban a session.use_only_cookies változó értékét 1 –re kell, hogy állítsuk (azaz engedélyeznünk kell a beállítást). A változtatás a munkamenet-kezelést nem befolyásolta, ez ki lett próbálva a javítás során. PHP Versions Prior to 5.2.13 (5.3.1) Multiple Vulnerabilities A webszerveren található PHP motor az 5.2.9-2 –es verziószámot viseli, a két egymáshoz hasonlító sérülékenység viszont azt jelzi, hogy elérhetőek frisebb verziók is belőle, azaz azok letöltésével és telepítésével biztonsági réseket foltozhatnánk be. Ezzel a sérülékenységgel a gyakorlatban viszonylag egyszerűen tudnánk foglalkozni, azonban a webszerveren futó webalkalmazás szerkezetét és nyelvének szintaktikáját olyan mértékben kellene leellenőrizni és átdolgozni az új verzióhoz való igazítás következtében, amelyre a webalkalmazás fejlesztőjének jelenleg nincsen kapacitása. A megrendelő a szubjektív javaslatomat megértette, és a biztonsági kockázatok tudatában a PHP motor aktuális verzióra történő frissítésétől eltekintett.
- 47 -
A javítások utáni mérés A webszerver tulajdonosával való időpontegyeztetés után lefuttattam az utolsó mérést. Várakozásom szerint két sérülékenységgel kevesebbet kell tapasztaljunk a javításoknak köszönhetően, továbbá azt, hogy azok a rések, amelyek javításával nem foglalkoztunk, a továbbiakban is jelenjenek meg a mérési eredményben. A mérési eredmény szembetűnő változásokat jelez a korábbiakhoz képest:
32. ÁBRA: AZ ELSŐ MÉRÉS RÉSZLETES EREDMÉNYE (RÉSZLET)
33. ÁBRA: AZ UTOLSÓ MÉRÉS RÉSZLETES EREDMÉNYE (RÉSZLET)
Az adott sérülékenységek eltűntek a rendszerből. Az újonnan megjelent potenciális sérülékenység a két mérés között eltelt időtartam alatti sérülékenységi adatbázis bővítésére utal (Zero Day vagy 0-day: frissen felfedezett biztonsági rés). A javításokat hatásosnak tartom, így a feladatban kitűzött célt sikerült elérnem.
- 48 -
4.2.9. Továbbfejlesztési lehetőségek Az eddig bemutatott vizsgálatok a webszerverre vonatkoztak kizárólag. Lehetőség
van
ugyanakkor
a
Qualys
szolgáltatásainak
felhasználásával
a
webalkalmazást is vizsgálni, ezzel letesztelhetőek például az SQL injection sérülékenységek, a session és autentikációs problémák feltárása valamint a fájlfeltöltések korlátozása érdekében beépített védelem állapota is. Érdekes lehet továbbá a Malware védelme is a szolgáltatónak, ez béta változatban van, ezért lehet még egy ideig ingyenes a fogyasztók számára.[25]
A méréseket rendszeressé is lehet tenni, és ezt követően trendet állítani fel a webszerver biztonságáról, ebben
segítségünkre lehet
az ütemezett sérülékenységvizsgálat
(Scheduled Vulnerability Test) funkció is. Itt lehetőségünk van a mérés pontos idejének és gyakoriságának meghatározására a 34. ábrán látható beállítások segítségével. Ezután automatikusan fog lefutni a vizsgálat a megadott paraméterek alapján.
34. ÁBRA: ÜTEMEZETT MÉRÉS BEÁLLÍTÁSA
- 49 -
5. ÖSSZEFOGLALÁS Az elmúlt évtizedek során nyílvánvalóvá vált, hogy az információ birtoklása kulcsfontosságú lehet annak érdekében, hogy a vállalatok a lehető legnagyobb részesedéssel rendelkezhessenek a piacon. Ebből adódóan az adatok védelmére fokozott figyelmet kell fordítaniuk, a sérülékenységvizsgálat éppen ehhez nyújt segítséget. A jelenlegi sérülékenységek többsége az alábbiakra vezethető vissza:
alkalmazások (operációs rendszer és egyéb szoftverek) frissítéseinek hiánya,
rosszul beállított konfigurációs állományok,
hiányos ismeretekkel rendelkező (az informatikai biztonság szempontjából inkompetens) alkalmazottak (Social Engineering, trójai programok)
Mivel nem várható el a cégek többségétől, hogy a rendszerüket folyamatosan a legnagyobb biztonságban tudhassák (ez irreális nagyságú kapacitásokat emésztene fel), napjainkban erre jó megoldás lehet a rendszeres állapotfelmérés független szakértők bevonásával, és az általuk dokumentált legnagyobb kockázattal járó események kivédésével. A dolgozatomban bemutatok egy, a piacon is elérhető szolgáltatást, amely teljes mértékben kielégíti a felmerülő igényeket, továbbá a szakmai támogatásnak köszönhetően dinamikus fejlődés alatt áll. A gyakorlati példában bemutatom, hogy egy általánosságban véve jól védettnek tekinthető, éles rendszer esetében is kulcsfontosságú lehet a sérülékenységvizsgálat a rendszer
megbízhatóságának
(reliability)
és
elérhetőségének
(availability)
maximalizálása érdekében. A feltárt sérülékenységek egy részét a dolgozat írása során kijavítottam, és a fejlesztés eredményét megismételt vizsgálattal támasztottam alá. A tapasztalatok alapján kimondhatom, hogy feltörhetetlen rendszer nem létezik, a kockázatokat viszont lehet csökkenteni (és kell is) az informatikai biztonság és az üzletmenet-folytonosság fenntartása érdekében.
- 50 -
6. ABSTRACT
It
became
of
information
share.
evident
in
might
Consequently,
the be
past vital
great
decades to
that
achieve
attention
must
for
the
be
companies,
greatest
paid
to
possession
possible
the
market
protection
of
data. Ethical Hacking provides assistance to this. Most of current vulnerabilities can be tracked back to the following:
The lack of updates to applications (operating system and other software)
Maladjusted configuration files
Employees with insufficient knowledge (incompetent by the means of information security) - Social Engineering, Trojan programs
Since
most
systems
companies
at
the
cannot
greatest
capacities
of
unreal
assistance
of
independent
hazardous
events
be
expected
possible
volume),
documented
by
continually
security
today
experts,
to
regular
and them
(that
keep
would
consume
check-ups
defending
against
might
a
be
their
with the
good
the most
solution.
In my paper I am presenting a service available on the market, which fully
satisfies
every
demand
in
the
matter
and,
thanks
to
professional
support, is under dynamic development. In the practical example I show that even in the case of a production system
that
inspection
can
can be
be
considered
essential
in
generally
maximizing
well-defended, the
system's
vulnerability reliability
and
availability. In the process of making my paper I have fixed some of the
detected
vulnerabilities,
and
confirmed
the
result
of
the
improvement with a repeated inspection. Based on my experiences I can say that there is no unbreakable system, but
risks
can
(and
should)
be
decreased
security and maintaining business continuity.
for
the
sake
of
information
- 51 -
7. IRODALOMJEGYZÉK [1]
Tanenbaum, A. S.: Számítógéphálózatok. Panem Könyvkiadó, 2004
[2]
Andrews, M., Whittaker, J. A.: How to Break Web Software: Functional and Security Testing of Web Applications and Web Services. Pearson Education, Inc., 2006
[3]
Vosseberg, T.: Hacker kézikönyv, Computer Panoráma Kiadó, 2002
[4]
BackTrack Linux, http://www.backtrack-linux.org, 2010-02-12
[5]
Tenable Nessus, http://www.nessus.org/nessus, 2010-02-12
[6]
QualysGuard, http://www.qualys.com/products/qg_suite, 2009-08-12
[7]
Buffer overflow, http://iac.dtic.mil/iatac/download/Vol7_No4.pdf, 2010-01-29
[8]
Brute force, http://www.cl.cam.ac.uk/~rnc1/brute.html, 2010-01-29
[9]
Wireshark, http://www.wireshark.org, 2010-01-30
[10] fping, http://www.fping.com, 2010-04-10 [11] Nmap, http://nmap.org, 2009-09-20 [12] Trojan horses, http://www.cert.org/advisories/CA-1999-02.html, 2010-05-18 [13] Denial of Service Attacks, http://www.cert.org/tech_tips/denial_of_service.html, 2010-03-24 [14] A Szolgáltatási Szint Megállapodás (SLA), http://tudastar.netacademia.net/default.aspx?upid=20648, 2010-05-18 [15] DDoS támadások és az ellenük való védekezés, http://hadmernok.hu/kulonszamok/robothadviseles7/gyanyi_rw7.html, 2010-05-06 [16] WHOIS, http://whois.domaintools.com, 2009-09-10
- 52 -
[17] Amit a Mydoom féreg változatairól tudni kell, http://www.microsoft.com/hun/biztonsag/mydoom.mspx, 2010-05-05 [18] Biztonságosabb jelszavak, http://www.haszon.hu/e-haszon/1346-biztonsagosabbjelszavak.html, 2010-04-05 [19] Intrusion Prevention Systems (IPS), http://hosteddocs.ittoolbox.com/BW013004.pdf, 2010-05-06 [20] Virasztó, T.: Titkosítás és adatrejtés, NetAcademia Kft., 2004. [21] Apache HTTP Server, http://httpd.apache.org, 2009-07-08 [22] MySQL adatbázis, http://www.mysql.com, 2009-10-13 [23] PHP, http://www.php.net/manual/en/install.windows.php, 2009-11-26 [24] Microsoft Windows XP, http://www.microsoft.com/windows/windows-xp, 2010-05-17 [25] QualysGuard Malware Detection, http://www.qualys.com/forms/trials/stopmalware, 2010-05-12
- 53 -
8. MELLÉKLETEK 8.1. Melléklet: Hozzájárulás sérülékenység vizsgálathoz (Mellékletek/Dokumentumok/Hozzajarulas.doc)
Hozzájárulás sérülékenység vizsgálathoz
Egyrészről az XY Informatika Rt. (székhely), továbbiakban mint Megrendelő Másrészről a Tanácsadó Kft. (székhely), továbbiakban mint Vállalkozó, együttesen Felek, Megrendelő hozzájárul, hogy Vállalkozó:
Legálisan összegyűjtsön minden olyan információt, mely munkájának elvégzéséhez szükséges,
munkája során legálisan használjon minden olyan külső rendszert, mely segítségével hozzáférhet a célzott számítógépes rendszerhez annak érdekében, hogy felmérje annak sérülékenységét,
Megrendelő kifejezetten olyan feladatok végrehajtására hatalmazza fel a Vállalkozót, melyek engedélyezés nélkül egyébként törvénybe ütköznének (sértett beleegyezése). Felek megegyeznek, hogy az egyes feladatok elvégzése előtt Vállalkozónak minden esetben kötelező konzultálni Megrendelővel. Ez a meghatalmazás a szerződés aláírásának napjától XXXX.XX.XX –ig érvényes. Munkavégzési kivételek Mindennemű, a Megrendelő üzleti, illetve informatikai tevékenységének megállítására, akadályoztatására irányuló tevékenység tiltott. Limitációk A Megrendelő elfogadja, hogy a Vállalkozó behatolási tesztje a teszt végzésének idejében rendelkezésre álló technológiákra támaszkodik. A Megrendelő tisztában van a teszt eredményeinek relatív természetével, amely a jelen állapotra vonatkozik és nem jelent garanciát a jövőbeli sérülékenységek vonatkozásában. Megrendelő tudomásul veszi, hogy a vizsgálatok nem teljes körűek, mintavételes eljáráson alapulnak.
Budapest, XXXX.XX.XX
Megrendelő
- 54 -
8.2. Melléklet: Apache access.log naplóállomány (Mellékletek/Naplóállományok/LOGS_20100327/APACHE/03/access.log) Az első mérés időpontja 2010:00:35:36. A mérőeszköz IP címe: 62.210.136.186. Jól látható az XSS sérülékenységet letesztelő HTTP kérés 2010:00:36:25 –kor. 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /JS/Association_Between_Label_Tagged_Img_And_Input.js HTTP/1.1" 200 1731 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /CSS/Style.css HTTP/1.1" 200 6758 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /JS/Validate.js HTTP/1.1" 200 4229 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /JS/MouseEventHandler.js HTTP/1.1" 200 2701 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /Images/Slices/images/Logo.png HTTP/1.1" 200 2589 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /images/reviewed.png HTTP/1.1" 200 6634 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /Images/Flag_HU.png HTTP/1.1" 200 3898 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /Images/Flag_EN.png HTTP/1.1" 200 3903 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /Images/Slices/images_en/mi_IDPhoto_3.png HTTP/1.1" 200 649 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /Images/Slices/images_en/mi_Help_1.png HTTP/1.1" 200 451 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /CSS/BackgroundTile_WGray.PNG HTTP/1.1" 200 2826 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /Images/Sample_01_EN.png HTTP/1.1" 200 123872 78.139.2.2 - - [27/Mar/2010:00:33:04 +0100] "GET /favicon.ico HTTP/1.1" 200 1150 78.139.2.2 - - [27/Mar/2010:00:33:05 +0100] "GET /Images/Slices/images_en/mi_Help_3.png HTTP/1.1" 200 455 78.139.2.2 - - [27/Mar/2010:00:33:10 +0100] "POST /index.php HTTP/1.1" 200 6007 78.139.2.2 - - [27/Mar/2010:00:33:14 +0100] "GET /Images/Slices/images_en/mi_IDPhoto_1.png HTTP/1.1" 200 634 78.139.2.2 - - [27/Mar/2010:00:33:14 +0100] "GET /Preview/Target/0000010579_484496811.jpg HTTP/1.1" 200 82405 78.139.2.2 - - [27/Mar/2010:00:33:14 +0100] "GET /Preview/Source/0000010579_484496811.jpg HTTP/1.1" 200 39625 78.139.2.2 - - [27/Mar/2010:00:33:14 +0100] "GET /Images/Slices/images_en/mi_Download_3.png HTTP/1.1" 200 579 78.139.2.2 - - [27/Mar/2010:00:33:14 +0100] "GET /Images/Slices/images_en/btn_SmallDown_1.png HTTP/1.1" 200 855 62.210.136.186 - - [27/Mar/2010:00:35:36 +0100] "GET / HTTP/1.1" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:16 +0100] "GET / HTTP/1.1" 200 16084 62.210.136.186 - - [27/Mar/2010:00:36:21 +0100] "GET / HTTP/1.0" 200 16084
- 55 -
62.210.136.186 - - [27/Mar/2010:00:36:21 +0100] "GET / HTTP/1.0" 200 16084 62.210.136.186 - - [27/Mar/2010:00:36:22 +0100] "GET / HTTP/1.0" 200 16084 62.210.136.186 - - [27/Mar/2010:00:36:22 +0100] "GET http://Qualys.null/ HTTP/1.0" 200 16084 62.210.136.186 - - [27/Mar/2010:00:36:23 +0100] "GET / HTTP/1.0" 200 16084 62.210.136.186 - - [27/Mar/2010:00:36:23 +0100] "GET / HTTP/1.1" 417 403 62.210.136.186 - - [27/Mar/2010:00:36:23 +0100] "GET / HTTP/1.0" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:23 +0100] "GET / HTTP/1.0" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:23 +0100] "GET / HTTP/1.0" 200 16084 62.210.136.186 - - [27/Mar/2010:00:36:23 +0100] "GET / HTTP/1.0" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:24 +0100] "GET / HTTP/1.0" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:24 +0100] "GET / HTTP/1.0" 200 16084 62.210.136.186 - - [27/Mar/2010:00:36:25 +0100] "GET /\"><script>alert(document.domain).html HTTP/1.1" 403 268 62.210.136.186 - - [27/Mar/2010:00:36:25 +0100] "GET /\"><script>alert(document.domain).html HTTP/1.1" 403 268 62.210.136.186 - - [27/Mar/2010:00:36:26 +0100] "GET / HTTP/1.1" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:26 +0100] "GET /../../../../../../../../../../../ HTTP/1.1" 400 226 62.210.136.186 - - [27/Mar/2010:00:36:26 +0100] "ABCD / HTTP/1.1" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:27 +0100] "GET /<script>alert(53416) HTTP/1.1" 403 243 62.210.136.186 - - [27/Mar/2010:00:36:27 +0100] "GET / HTTP/1.1" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:29 +0100] "GET / HTTP/1.1" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:29 +0100] "GET / HTTP/1.0" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:30 +0100] "GET /jqsuzzpux1cch8p853e HTTP/1.1" 404 217 62.210.136.186 - - [27/Mar/2010:00:36:30 +0100] "GET /index.html HTTP/1.1" 200 114 62.210.136.186 - - [27/Mar/2010:00:36:30 +0100] "GET / HTTP/1.1" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:30 +0100] "GET /index.html HTTP/1.1" 200 114 62.210.136.186 - - [27/Mar/2010:00:36:30 +0100] "QUALYS / HTTP/1.1" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:31 +0100] "OPTIONS / HTTP/1.1" 200 22271 62.210.136.186 - - [27/Mar/2010:00:36:32 +0100] "TRACE / HTTP/1.1" 200 49
- 56 -
8.3. Melléklet: Apache error.log naplóállomány (Mellékletek/Naplóállományok/LOGS_20100327/APACHE/03/error.log) Az első mérés időpontja 2010:00:35:36. A mérőeszköz IP címe: 62.210.136.186. Megfigyelhető, hogy 00:36:25 –ös naplóbejegyzésben a HTTP kérés hibát eredményez, mégis teljesíti azt a mérőeszköz felé. Ezután olyan állományokat illetve könyvtárakat keres az eszköz a webszerveren, amelyek általában elő szoktak fordulni a kiszolgálókon, erre egy példa a 00:36:33 –as bejegyzés, amelyben index.html –hez próbált hozzáférni. [Sat Mar 27 00:18:10 2010] [notice] Child 3080: Starting 64 worker threads. [Sat Mar 27 00:18:10 2010] [notice] Child 3080: Starting thread to listen on port 80. [Sat Mar 27 00:19:42 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:19:42 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:19:44 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:32:09 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:35:30 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:35:30 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:35:31 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:35:31 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:35:32 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:35:34 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:35:37 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:35:42 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:36:15 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:36:15 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:36:15 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:36:15 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:36:25 2010] [error] [client 62.210.136.186] (20024)The given path is misformatted or contained invalid characters: Cannot map GET /"><script>alert(document.domain).html HTTP/1.1 to file
- 57 -
[Sat Mar 27 00:36:25 2010] [error] [client 62.210.136.186] (20024)The given path is misformatted or contained invalid characters: Cannot map GET /"><script>alert(document.domain).html HTTP/1.1 to file [Sat Mar 27 00:36:26 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:36:26 2010] [error] [client 62.210.136.186] Invalid URI in request GET /../../../../../../../../../../../ HTTP/1.1 [Sat Mar 27 00:36:27 2010] [error] [client 62.210.136.186] (20024)The given path is misformatted or contained invalid characters: Cannot map GET /<script>alert(53416) HTTP/1.1 to file [Sat Mar 27 00:36:28 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:36:29 2010] [warn] (OS 64)A megadott hálózatnév már nem érhető el. : winnt_accept: Asynchronous AcceptEx failed. [Sat Mar 27 00:36:30 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/jqsuzzpux1cch8p853e [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /index.html [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] Invalid URI in request GET /../index.html HTTP/1.1 [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] Invalid URI in request GET /../ HTTP/1.1 [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/formmail.html [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/mailform.html [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/phpnuke [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/gallery [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/~root [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/kovhgqcr1_zu [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/formmailto.html [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] script 'F:/WEBSITE/IDPhoto/add_comment.php' not found or unable to stat [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/default.asp [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/iwe2h1l77z8we8 [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/mailtoform.html [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/advadmin [Sat Mar 27 00:36:33 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/l2_if9504 [Sat Mar 27 00:36:34 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/actionpoll-1.1.1 [Sat Mar 27 00:36:34 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/form.html [Sat Mar 27 00:36:34 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/advwebadmin [Sat Mar 27 00:36:34 2010] [error] [client 62.210.136.186] File does not exist: F:/WEBSITE/IDPhoto/b9lyt_7tsc1
