1 Biztonsági tesztek predikciójának kutatása május 22. Készítette: Boadree Innovations Kft. Székhelye: 1201 Budapest, Alsóteleki u. 92.; Cégjegyzékszá...
1.1. Vezetői összefoglaló A jelen dokumentum témája: a biztonsági tesztek predikciójának kutatása. Azaz, hogyan válasszuk ki a legígéretesebb teszteket a látott célrendszerek biztonsági problémáinak azonosítására vagy megalapozott kikövetkeztetésére. A tervezett rendszer egyik fontos hozadéka lenne, hogy az ügyfél szolgáltatásai minimális terhelésnek legyenek kitéve, és ezáltal a biztonságot vizsgáló rendszerünk használható legyen akár egy éles környezettel szemben is - ez a próbák okos kiválasztása nélkül nem lehetséges. Első lépés, hogy megtaláljuk és azonosítsuk a HTML alapú szolgáltatást végző rendszereket1. A második, hogy okosan kiválasszuk a célrendszer biztonságát vizsgáló teszteket. Ideális esetben a célrendszer megbízhatóan pontos azonosítása lehetőséget adhat arra, hogy sérülékenység próbák nélkül is biztonsági diagnózist tudjunk adni egy sérülékenységnyilvántartás alapján. A gyakorlatban a megbízható diagnózis az ismert rendszer konkrét konfigurációjának is függvénye. Ilyen nyilvántartás (tudásbázis) alapú megközelítéssel a “Biztonsági sérülékenységek online forrásokból történő automatikus kigyűjtésének kutatása” c. dokumentumban részletesebben foglalkozunk. Itt a kikövetkeztetés feladatát két irányból vizsgáljuk: ujjlenyomat alapján és próbák alapján. Illetve foglalkozunk azzal is, hogyan jósolhatjuk meg, mely biztonsági tesztek fedeznek majd fel sérülékenységet a felderített célrendszeren. Az alábbiakban nagyobb terjedelemben körképet adunk a rendszerek és sérülékenységek felderítésével kapcsolatos létező eszközökről és röviden elemezzük a használatukat is. Feladatkörökre tagolva tekintjük át a létező rendszereket, igyekezve bemutatni az audit gyakorlatában fajsúlyos vagy az adott feladatkör megoldása szempontjából mérvadó eszközöket. Láthatjuk, hogy a biztonsági audit elérhető eszközkészletének tudása kiforrott. Kitérünk arra is, hogy a webes szolgáltatást végző rendszerek nyilvános felületeken felderíthető milyen jellemzőire érdemes támaszkodni abban, hogy beazonosítsuk a látott célrendszert és annak potenciális sérülékenységeit megjósolhassuk, illetve milyen rendszerjellemzőkre lehet érdemes támaszkodni gépi tanulás során. (A jellemzők tárolását illetően
1
Illetve, ahogy a “Webes szolgáltatások beazonosíthatóságának kutatása” dokumentumban
írtuk, jelen fázisban az elterjedt CMS rendszerek azonosítása cél.
4
egy fon ntos írány a sérülékeny ységek publiikus táraiva al kapcsolattos - ezt a ttémát a “Bizztonsági sérülékenységek
online
fo orrásokból
történő
automatiku us
kigyűjttésének
kutatása”
t dokumeentumban tárgyaljuk.)
1.2. Alapfog galmak k és tago olás Az érdeeklődésünk látókörébe en alapvetőeen a HTML L-alapú szo olgáltatást vvégző alkalm mazások vannak k (most első ő sorban ezzek közül iss a CMS reendszerek). Ezek feldeerítéséhez azonban a széleseb bb körben és eggyell mélyebb szinten is i kell vizsgálódnunkk. A HTM ML-alapú szolgálttatást TCP protokollo on HTTP-tt szolgáltató hosztoktól kaphatu unk, ezért fel kell derítsük k az ún. intternet (IP) rétegben láátható szolg gáltatási po ontokat (poortokat), eze ek közül megnézzni a HTTP P vagy SSL--be csomaggolt HTTP szolgáltatásst végző poontokat (úja abban a HTTP, értsd HT TTP 1.1, mellett m érdeemes SPD DY-ra is go ondolni)2. Ahogy a “Webes szolgálttatások bea azonosítható óságának kkutatása” c. dokumenttumban látttuk, az alk kalmazás hibák eegy része neem az alkallmazás felh asználói intterfészében n (HTML) jeelentkezik (lásd pl. SQL vagy file szintten elérhető ő sérüléken nységek), ezért a felderítésünk sorrán más alk kalmazás szintű p protokolloka at is fel kell derítsünk. Az aláábbi wikipéédiás ábra a3 szemléltteti az intternet (TC CP/IP) réteegeket (a témánk szempo ontjából gon ndolatban csseréljük ki aaz UDP-t TC CP-re):
Az alkallmazás réteegen kívül a transzport (TCP) és azz internet (IIP) rétegben n is vizsgáló ódunk.
Az ilyen tagolás messze nem egyértelmű, viszont igazodik a sérülékeny rendszerek és a sérülékenységek (dinamikus) keresésében használt eszközöknek a gyakorlatban bevett tagolásához - ezért alkalmazzuk. A hálózati elemek és szolgáltatások feltérképezésével a sérülékenység szkennerek is foglalkoznak, de fő céljuknak az ismert alkalmazások és egyéb rendszerek ismert sérülékenységeinek keresését tartjuk. A web szkennerek fő céljának pedig egy tetszőleges HTML-alapú alkalmazás sérülékenységeinek kiderítését. Az alábbi ‘Felderítés létező eszközei’ c. fejezetben ebben a hármas tagolásban sorra vesszük a sérülékenység dinamikus tesztelésben legelterjedtebb eszközöket, szkennereket. Ezek tárgyalásával az a cél, hogy teljes képet kapjunk arról, hogyan szokás és lehet ma sérülékenységet keresni dinamikus módszerekkel, azaz élő rendszeren. A “Webes szolgáltatások beazonosíthatóságának kutatása” c. dokumentumban már említettük, hogy a sérülékenységkeresésnek két fő módja adott: dinamikus és statikus, kifejtettebb neveken: Dynamic Application Security Testing (DAST) és Static Application Security Testing (SAST). Az utóbbi körbe tartoznak azok a módszerek, amikor nem élő alkalmazáson vizsgáljuk a problémákat, hanem a rendelkezésünkre áll az alkalmazás forráskódja, vagy ahhoz hasonló kód (bytecode), vagy valamiféle visszafejtett kód (tehát egy futtatható bináris állomány is lehet tárgya a SAST vizsgálatnak). A statikus tesztelés elméletileg nagyságrenddel hatékonyabb abból a szemszögből nézve, hogy a dinamikus tesztelés során lényegében egy fekete dobozt4 vizsgálunk a felületén látható interfészeket, funkcionalitásokat manipulálva (kívülről), és így nehéz a vizsgálattal lefedni az összes problémás pontot (lásd még a coverage fogalmát), illetve nehéz optimalizálni a vizsgálatot nagyobb figyelmet szánva a biztonsági szempontból kritikus pontoknak. A dinamikus tesztelés esetlegesebb és zajosabb, akár szakértők, akár automaták végzik. A statikus Ezért is nevezik az ilyen módszereket black-box tesztelésnek. Ez a kifejezés nem specifikusan a biztonsági tesztelések sajátja, hanem a szoftver tesztelésben általában használt fogalom. A black-box tesztelőnek nem állnak rendelkezésére a rendszer belső működését leíró információk. Ha a tesztelő a forráskódot vizsgálná, azt white-box tesztelésnek neveznénk. A grey-box teszt esetéről akkor beszélünk, ha a belső működésről lényeges ismeretek állnak rendelkezésre, például sémák vagy leíró dokumentáció. Az utóbbi eset jellemző az egyedi fejlesztésű vállalati alkalmazások esetében, ezért nem automatikus, hanem elemző szakértőkkel történő biztonsági tesztelés alkalmazása esetén erősen ajánlott. A black és grey megkülönböztetésbe bele szokták keverni azt is, hogy a tesztelő kap-e jogosultságokat a tesztelt rendszerhez, így a tiszta black-box a rendszert távolról elérő hacker esetével látszik azonosnak, a grey-box pedig a szoftver fejlesztés során alkalmazott humán teszteléshez. 4
6
vizsgálatok tiszta fajtája a forráskódot vizsgálja, amit számos kifejezetten SAST eszköz és más forráskód analizáló eszközök támogatnak, de ugyanúgy jelentős helye van a humán szakértőnek. Code-review, forráskód-vizsgálat esetében alapvetően a humán szakértő által végzett vizsgálatra gondolunk, aki képes felmérni, hogyan működik az alkalmazás, mely részein képes elbukni a vállalati erőforrások és folyamatok védelme, mely részei felelősek a biztonsági funkcionalitásért. A kód-vizsgálat során a fejlesztőket is meg szokás interjúvolni, ha erre van lehetőség. A statikus és a dinamikus keresésnek hibrid formája is létezik, a hibrid változatok közül a legelterjedtebb az ún. Interactive Application Security Testing (IAST), amikor az alkalmazásba a biztonsági problémákat tetten érő szondákat építenek be, és azok jelzéseit egy rendszer vizsgálja. A tárgyalásunk látókörében a valós rendszerek sérülékenységeinek dinamikus keresése áll, azaz a DAST. Ekkor futó rendszereket vizsgálunk kívülről. A futó rendszerek biztonsági vizsgálata nem garantálja azok működésének zavartalanságát, mert definíció szerűen nem tervezett működést hivatott előidézni, ezért az éles rendszerek tesztekkel történő biztonsági vizsgálata nem javasolt. DAST vizsgálatokat általában teszt környezetben végzünk, ahol nem probléma, ha a tesztelések során inkonzisztens állapotban kerül a rendszer, adatok vésznek el vagy módosulnak. Nem biztonsági célú szoftver-tesztelés jellemzően előre megírt teszt-forgatókönyvek szerint történik, és a szoftver rendeltetésszerű használatát imitálja. A biztonsági tesztelés általában rejtett hibákat keres és dinamikus tesztelés esetében olyan trükkös módokon szólítja meg a szoftvert, hogy hozzáférés nyíljon az egyébként nem elérhető funkcionalitáshoz, adatokhoz, vagy egyéb módon idézzen elő olyan, a támadó számára kívánatos, de a felhasználó szervezet számára káros következményekhez, melyekre a fejlesztő mérnőkök nem számítottak. Egy éles rendszer ilyen célú tesztelése üzleti kockázat, adott esetben üzletmenet folytonosságot is veszélyeztető tevékenység. Ezért ideális lenne egy olyan tesztelő rendszer kifejlesztése, mely nem intruzív módon azonosítja a vállalati környezetben futó éles rendszereket, megállapítja azok milyenségét és verzióját (patchlevel szintig), ezek alapján jósolja meg, milyen ismert biztonsági hibák lehetnek jelen. Ezek meglétének nem intruzív ellenőrzésére korlátozódna az éles tesztelés. Így az ügyfél szolgáltatásai minimális terhelésnek lennének kitéve az ilyen tesztelés során. Tiszta esetben az aktívan támogatott ismert rendszerekben az ismert sérülékenységeket a legutolsó kiadás nem tartalmazza vagy a legújabban kiadott patch-ek befoltozzák, tehát az elméleti feladatunk átlapol a vállalati szoftverek teljes inventarizációja, pontos nyilvántartása és a patch management területével. (Illetve marad az ismert, de még nem javított sérülékenységek szűk köre. A nem ismert sérülékenységek felfedezése ismert rendszerekben 7
pedig a látókörünkön kívül esik.) A valóságban nem jellemzők tiszta esetek és az ismert rendszereken is számos egyedi módosítással működnek, így marad a feladat: nagy pontossággal megjósolni, hogy adott webes szolgáltatáson mely biztonsági tesztek fedeznének fel sérülékenységet, felhasználva az adott szolgáltatás nyilvános felülete alapján megállapítható jellemzőket. A 3. fejezetben foglalkozunk a DAST eszközök áttekintése alapján adódó olyan jellemzőkkel, melyek az alkalmazások biztonsági problémáihoz prekurzív módon kötődnek. A 4. fejezetben foglalkozunk a gépi tanulás lehetőségeinek előzetes tárgyalásával.
2. Felderítés létező eszközei 2.1. Hálózati felderítés 2.1.1. Bevezetés Az alkalmazásik hibáinak felderítéséhez a végpontok, azaz hosztok felderítésével és az azokon való szolgáltatások feltérképezésével lehet közelebb jutni. Tehát az alkalmazások sérülékenységeinek keresésében járulékos feladat a TCP/IP hálózatban látható szolgáltatási pontok feltérképezése. További járulékos feladat az, hogy kezeljük a hálózatban rejlő különböző védelmi megoldásokat, melyek védik az alkalmazásokat az illetéktelen hozzáféréstől, szűrik a kéréseinket, trükköznek a hálózati forgalom áramlásával, letiltják a kapcsolatunkat rendszerek felé, ha támadó jellegűnek találják a forgalmazásunkat. És ne felejtsük el, valóban olyan viselkedési mintákat produkálunk a hálózaton, mint amilyeneket egy hacker adhat elő. Tehát számíthatunk arra, hogy a vizsgálódásaink védelmi intézkedésekbe torkollanak - ez egy külön téma, amivel jelen dokumentumban nem foglalkozunk. Amikor a hálózati felderítés eszközeit és technikáit tekintjük át, érdemes emlékezni arra, hogy jellemzően egy olyan korszak megoldásait látjuk, melyben a hálózat volt a fő védelmi vonal a vállalati erőforrások és alkalmazások előtt. Ezek a megoldások az eredetileg kooperatív TCP/IP konstrukciókat paranoid elemekkel bonyolították el. Még pár éve az volt az elképzelés, hogy az alkalmazásokat az védi meg, hogy a hálózatot zónákba szervezzük, a zónákat ún. határvédelemmel látjuk el, és legfőképpen a nyílt internet felé építünk fel hátárvédelmi vonalakat. Ilyen paradigmában az internetről jövő forgalom az ún. DMZ (demilitarizált zóna) szervereiben landolt és kapott válaszokat, ezekről a szerverekről azt 8
feltételeeztük, hogyy eleshetnek a támad dók feltöréssi kísérletei során, dee a vállalat értékes adatbázzisai a jobba an védett belső hálózaati szegmenssekben vannak, ezért aazokhoz a hackerek h nem férrnek hozzá. A DMZ elk képzelést mu utatja az alá ábbi ábra5:
Egyszerrű szolgálta atási archittektúra és ffolyamatok k mellett ezzek a védel elmi prekon ncepciók működttek, de az id dők során allapvetően téévesnek bizzonyultak. Főbb F problém mák:
A modern alkalmazás a architektúrra már nem tagolható jól a fenti kooncepció szerint, az adatok és a védett üzle eti logika neem választh hatók le az internetet i kkiszolgáló szzerverek működésérről ennyire átlátható á m módon.
A legfőbb b probléma a éppen az, amiértt az alka almazások
sérülékeny ységeivel
foglalkozun nk, éspedig g az, hogy a hackereek az alkalmazásokbaan használják ki a biztonsági kockázatok kkal járó hiibákat, és ezt e az alkalmazások álltal kifelé mutatott m n teszik. Ez az interfacce by design átnéz a DMZ D és egyyéb hálózatti szintű interfészen védelmi eszzközökön, a hack az allkalmazás rétegben r törrténik, amitt az alantass szintek nem értelm mezik.
A vállalati adatvagyon nt és folyam matokat érrő támadások nagyobbb részben éppen é a belső hálózzat felől (LA AN) történneek.
A belső válllalati funkciók akár j elentős részben is küllső partnereek által vallósulnak meg, ezért az interne et és intran net elhatáro olásban megjelenik azz extranet fogalma, f mely végkééppen összezzavarja a feenti ábrán léévő tiszta villágképet kéépet.
A vállalati szerverek jelentős rrésze legtöb bb esetben nem a váállalat sajátt fizikai infrastruktú úrájában helyezkedne h ek el, hanem m datacentterekben. A cloud com mputing elterjedésévvel a vállala ati informattikában má ár előfordulh hat, hogy m maga a válla alat sem tudja, milyeen fizikai szzervereken kkapnak hely yet a virtuállis szervereii.
A rugalmasan skálázható virtualizált környezetek használatának elterjedése az utóbbi években, és a konténeres architektúrák most várható elterjedése végképp lerombolja a korábbi paradigmát, mely - lássuk be - fizikailag tagolt hálózati infrastruktúrában gondolkodott.
A problémák (a körülmények változása) miatt a modern vállalati hálózat több irányba változik: ●
Egyrészt LAN és WAN felé egyaránt szigorú hozzáférés védelmi intézkedések, tűzfal és routolási szabályok lettek érvényesek. Sőt a LAN bonyolultsága miatt a LAN szabályok még bonyolultabbak is.
●
A belső vállalati forgalom egyre nagyobb része védve válik a köztes lehallgatás ellen, például az SSL-be csomagolt HTTP-re kell számítsunk belül is.
●
A hálózati tűzfal koncepció tovább fejlődött a WAF, web application firewall irányába, azaz az alkalmazás rétegű forgalom szűrésébe, ahol a forgalom üzleti és egyéb magas szintű szimbólumai alapján lehet döntéseket hozni a közlekedő kérések és válaszok legitimitásáról, illetve tetten érni a visszaélési mintákat.
●
A hálózati szinten is nagyobb lett a behatolás érzékelésre eső hangsúly a védelem bonyolításával szemben (lásd IDS6).
●
Általában a védelemben való hitet felváltja az a szemlélet, hogy szinte elkerülhetetlen, hogy a rendszereinkbe betörnek, így a biztonsági szakma a támadások kárainak a csökkentésébe, a támadások gyors lekezelésében kell nagyobb energiákat fektessen (lásd IR7).
Tehát ilyen kihívások mellett kell dolgoznia a rendszerünknek a hálózatban szolgáltatási pontokat felderítő részének. Több szoftver is fellelhető, ami egy hálózat vagy hálózati szegmensen található szolgáltatások felderítésében lehet segítségünkre. Ezek megmondják, hogy milyen hoszton, milyen porton milyen szolgáltatás fut. Az eszközök taglalása előtt még tisztáznunk kell az IP port alapfogalmát és az alapműködést, a port szkennelést. IP port A port fogalma a hálózat és a hálózati szolgáltatások dizájnjának része. Az IP port konstrukciója lehetővé teszi, hogy az IP által megcímezhető végpontokon, hosztokon
különböző szolgáltatási pontok legyenek megcímezhetők a TCP és UDP protokollok számára. A mi szempontunkból elsősorban az lenne érdekes, hogy egy adott hoszton több HTTP alapú szolgáltatás is helyet kaphat különböző portokon. És ez a felderítési feladat összeolvad azzal, hogy ugyanannak a hosztnak lehet több megszólítható szolgáltatása a címzéshez használt IP vagy domain név függvényében (lásd pl. virtuális hoszt) vagy az URL útvonal függvényében (lásd a “Webes szolgáltatások beazonosíthatóságának kutatása” c. dokumentumban a ‘Webes alkalmazások felfedezése a szerveren’ c. részt). Tehát a szamlazas.kozpontiszerver.hu, kozpontiszerver.hu/szamlazas és a kozpontiszerver.hu:8008 címzések ugyanazt a célt szolgálják. Humán felhasználás számára az explicit port megadást igénylő címzés kevéssé barátságos, ezért nem lehet általános. Vannak megszokott konvenciók, mint például a korábban említett Tomcat admin panel a 8080-as porton, és szólhatnak érvek a szolgáltatások (szerver példányok) különböző portokra konfigurálására (például tűzfal szabályokkal való védelem), de manapság egyre inkább a portok nélküli URL-ek kiajánlása a jellemző webes UI esetén. A hoszton figyelő, élő szolgáltatások között a számunkra érdekes HTTP (HTTPS) szolgáltatás általában kevésszámú lehet. Humán HTML interfészt (webes UI) a legtöbb esetben a normál (implicit) 80-as vagy a https, 443-as port fogja szolgáltatni. A fent elmondott korszerű fejlemények miatt egyre inkább a 443 HTTP/SSL lesz az alkalmazások portja a belső webes szolgáltatások esetében is. Az alkalmazás szintű (API) HTTP interfészek elhelyezkedhetnek explicit portokon, szerverszerver kommunikációban kézenfekvő az egyedi portok megadása, ugyanakkor az ötletszerű porthasználat követhetetlen vállalati gyakorlatot eredményezhet, ezért inkább elképzelhető vállalati konvenció néhány házirendben javasolt egyedi portról. A mobil applikációk, mint szolgáltatás kliensek használatának tömeges terjedése akár elő is mozdíthatná a speciális portok használatát. De az Internetre kiajánlott alkalmazás interfészek esetében is a 443-as port a nyerő, mert a speciális portokat tilthatnak internet szolgáltatók, és túl sok panasz fog érkezni az ügyfélszolgálatunkra (a 80-as port esetére itt nem gondolunk, mert eleve rossz gyakorlatot feltételez, lehallgatható kommunikációt a kliensek felé). Az elmondottak alapján szkennelés nélkül is tudhatjuk, hogy az adott vállalati környezetben mely portokon várható a HTTP(S) szolgáltatások jelenléte, az egyéb portokon talált HTTP szolgáltatások eleve biztonsági problémát fognak jelezni, a házirendtől való eltérést. Tekintettel kell lenni arra is, hogy a routerek előtti forgalom portjai eltérhetnek a forgalom belső célját jelentő szerver portjától. Így az internetes felhasználók felé néző 443-as portot lehet, hogy az intraneten (DMZ-ben) egy szerver egy speciális porton szolgálja ki (megtartva a publikus sztenderd port előnyeit, de belül egyéb konvenciókat követve). Egy fix külső IP 11
esetébeen is értelmees megoldás lehet több b speciális portra p tennii a különbözző szolgálta atásokat, melyek belül meg gtalálják a saját s szerveerüket.8 No oha továbbrra is igaz, h hogy több érv szól amellettt, hogy egyy domain 443-as 4 porrtjára érkezzzen a HTT TP forgalom m, a szolgá áltatások eltérítésse inkább az subdom main vagyy URL tag golás alapjá án vezérelőődjön (web bszerver funkcio onalitással). Valós (ffizikai vagy virtualizáltt) hosztok eesetében néh hány konve encionális p porton figye elő (vagy azokon válaszoló) hálózati szolgáltatás s sra lehet szzámítani (p pl. DHCP, 67, 68, DNS, D 53, NetBIO OS, 137-139 9, NTP, 123, illetve aaz ICMP támogatásá t ra). Azonbban arra nem kell számítaani, hogy mi m is nyitotttnak láthatjjuk ezeket a technikai portokat, m mert jól ko onstruált tűzfal sszabályok azz ezekhez való v hozzáféérést dedik kált források kból (IP) jöövő kérésne ek teszik csak leh hetővé. A port sszkennelés része az ICM MP protoko oll használa ata is, az eze en küldött kkérések és válaszok, v noha aaz ICMP (Internet ( Control C Meessage Prottocol) protokoll függeetlen a TC CP/UDP protoko olltól és így a portok fo ogalmától ( és ebben a 7-es számú ú ping port se tévessze e meg az olvasót))9. Az ICMP P különböző ő hálózati diiagnosztikai, kontroll és é hiba üzen neteket való ósít meg, és mintt ilyen alkalm mas a hoszttok felderítéésére is. Tip pikusan ide tartozik a p ping funkcio onalitás, melynek k tiltása va agy meghag gyása főleg a szervezettnél uralkod dó adminiszztrátori hitv vallástól függ. A port scan legtöb bb ügyes technikája (láásd lentebb b) a TCP prrotokoll han ndshake ele emeit és nálja ki. Ha andshake réészleteire nem n térünk itt ki, az éérdeklődő olvasót o a sajátossságait haszn Wikipéd dia idevona atkozó szóccikkéhez uttaljuk.10 Alapelképzelé és érdekébeen közlünk k itt egy ábrát11:
Az ábrán érdemes látni, hogy szinkronizációs (SYN) és visszaigazoló (ACK) TCP üzenetek váltása történik, a szinkronizáció alapvetően arról szól, hogy további forgalmazásban a TCP csomagok mindkét irányban monoton növekvő sorszámokat kapnak a forgalmazás megbízhatósága érdekében. Az IP portok témában még érdemes tekintettel lenni arra, hogy az IP forgalom esetében ugyan feltételezzük, hogy az IPv4, de egyre elterjedtebb az IPv6 is, mely független forgalmazási teret jelent, és abban a szolgáltatásokat külön fel kell deríteni. Port scan A port scan során a célpontok nyitott portjait keressük. De magukat a hálózati célpontokat, a hosztokat is port scan technikával találjuk meg. (Illetve megkülönböztetjük még a portsweep eljárást, amikor egy bizonyos port nyitottságára nézve vizsgálunk végig hálózati végpontokat, hosztokat.) Egy port állapota lehet open vagy closed: ●
open - Azt jelenti, hogy egy alkalmazás vagy szolgáltatás figyel az adott porton. Illetve pontosabban azt, hogy ezt a figyelő alkalmazást láthatjuk is a saját hálózati helyünkről (és a csomagjaink egyéb jellemzői sem kontraindikálják, hogy láthassuk). Nem biztonsági célú hálózati szkennelés számára a nyitott port egy újabb potenciálisan hasznos szolgáltatást jelent. Számunkra pedig a nyitott port jelenthet egy
vagy
több újabb potenciális alkalmazást, vagy
HTTP API-t, melyek
sérülékenységeit vizsgálhatjuk. (Egy penetrációs tesztelő számára pedig akármilyen nyitott szolgáltatás közvetítő pontot jelenthet a direktben nem elérhető más szerverek felé.) ●
closed - Zárt port, nem figyel rajta szolgáltatás vagy nekünk azt látni nem szabad. Ez amúgy a másik oldal segítőkész válasza, az openhez hasonlóan kapunk választ a túloldalról, adott esetben, hogy a port nem szolgáltat (és lehet, hogy más információt is). (Az sem kizárható, hogy a tűzfal szabályok olyanok, hogy csak felénk állítják, hogy nincs szolgáltatás.) A hálózati topológia felderítése szempontjából ez a válasz már értékes, elkönyvelhetjük, hogy az adott IP él, legalább egy hálózati interface vagy virtuális végpont kezeli az arra érkező IP csomagokat. (Elképzelhető, hogy a zárt port egyszer csak szolgáltatni fog, ezért érdemes azt visszatérően ellenőrizni, ha tökéletességre törekszünk.)
A port szkennelés szempontjából (általában az Nmap fogalmait használva) értelmezünk még bizonytalan állapotokat:
13
●
filtered - Létezőnek tételezett portól nem érkezik válasz a kéréseinkre. Vegyük észre, hogy ezt akkor állíthatjuk, hogy ha egyébként alaposan feltételezzük, hogy maga az IP (host) él, például az alapján, hogy más portokon vagy ICMP-vel az adott IP-ről (hosztról) már kaptunk visszajelzést. A legtöbb esetben ez azt jelentheti, hogy egy csomagszűrő szolgáltatás (tűzfal vagy router) eldobja (drop) a portra (legalábbis a felőlünk) jövő csomagokat. Mivel az is lehetséges, hogy hálózati problémák nem érkezik válasz a kérésünkre, ezért a port szkenner csak többszöri próbálkozás után jelentheti ki, hogy a portra küldött kérések egy szűrű áldozatául esnek anélkül, hogy a port nyitottságát vagy zártságát illető válasz érkezne vissza.
●
UNfiltered - A létezőnek tételezett portról ugyan érkezik válasz a (TCP ACK) trükkös kérésünkre (újabb bizonyságul, hogy a port létezik), de nem lehet eldönteni, hogy zárt-e vagy nyitott.
●
open|filtered és closed|filtered - Nmap terminológiában ezek a bizonytalan port állapotok azt jelzik, hogy a további tesztek ezek között az állapotok között kell döntsenek.
Különböző szkennelési technikák léteznek, ezek közül mutatunk be néhányat, amit a későbbiekben használni fogunk az alkalmazások segítségével:12 TCP connect scan Ez az egyik legegyszerűbb szkennelési módszer. Megpróbál csatlakozni (connect) az adott portra, ami ha nyitva van, akkor sikerül és egyből zárja. Előnyei: ●
minden operációs rendszeren működik,
●
nem kell hozzá speciális jogosultság.
Hátrányai: ●
Rendszergazdák értesítéseket fognak kapni a tűzfaltól a próbálkozásról.
TCP SYN scan A TCP SYN scan során egy be nem fejezett TCP kapcsolódást hajt végre. A scanner egy SYN csomagot küld a célnak, ami, ha az adott port nyitva van, akkor egy SYN|ACK csomaggal válaszol, amit ha megkaptunk egyből zárjuk a kapcsolatot egy RST csomaggal. Ha a port nincs nyitva, akkor egy RST csomagot küld a célgép.
12
Forrás: http://hu.wikipedia.org/wiki/Port_scan 14
Előnye: ●
Mivel a kapcsolatot nem fejezzük be, ezért sok rendszer nem veszi kapcsolódási kísérletnek, tehát kevesebb logbejegyzés készül.
Hátránya: ●
Rendszergazdák értesítéseket fognak kapni a tűzfaltól a próbálkozásról.
TCP FIN/Xmas/Null scan Ebben az esetben nem építünk ki kapcsolatot, hanem küldünk egy FIN csomagot, amire ha az adott port nyitva van, nem kapunk választ (hiszen nem egy fennálló kapcsolathoz tartozik), viszont abban az esetben, amikor a port zárva van, egy RST csomagot kapunk válaszul. Előnye: ●
csendesebb, mint a TCP SYN scan.
Hátránya: ●
Microsoft operációs rendszerek nem válaszolnak semmilyen előzmény nélküli FIN csomagra sem.
TCP (IP ID) Idle scan Ennél a módszernél olyan módosított csomagokat küldünk a célpontnak, amiben úgy módosítjuk a forrás címét, mintha egy másik gép (az ún. zombi) küldte volna. Az IP csomagok fejlécében található egyedi azonosítót (IP ID) használja ki ez a módszer. A protokoll implementációjában úgy valósították meg ennek az ID-nek a generálását, hogy minden küldés után eggyel növeli az azonosítót. Ennek segítségével meg tudjuk mondani, hogy két csomag között hány csomag volt elküldve az adott gép által. ●
Válasszunk egy zombi gépet, aminek lekérjük az aktuális IP ID-jét.
●
Küldjük ki a SYN csomagot a célgépnek, a zombi gép nevében.
●
Ha a célgépen nyitva volt a port, akkor SYN/ACK csomagot küld a zombi gépnek, hiszen azt látja ő kezdeményezte a kapcsolatot.
●
Ezután a zombi gép RST csomagot küld a célgépnek, mert nem ő küldte a SYN csomagot.
●
Mivel a zombi gép küldött egy RST csomagot, ezért az IP ID-je nőni fog, innen tudhatjuk, hogy nyitva volt az adott port a célgépen. 15
●
Az utolsó léépésben, am mikor lekérjjük az IP ID D-jét a zomb bi gépnek, kkettővel kelll nőnie, hiszen küld dött egy RST T-t a célgépn nek, illetve nekünk a mostani m válaaszt az IP ID D-jével.
●
Ha az adottt port nem volt v nyitva, akkor eggy yel nőtt az IP P ID.
kat az alább bi ábra szem mlélteti13: A leírtak
Előnye:: ●
Megkerülheetjük a tűzffal beállításo okat.
Hátrányya: ●
Eséllyel ha aszontalan technika, t m mert az IP ID-k generálása és kkiosztása már m nem ennyire kövvethető.
UDP sccan gáltatás az interneten i T TCP protok kollon keresztül fut, UD DP szolgálta atások is Bár a leegtöbb szolg széleskö örben elterjjedtek, mintt például DN NS, DHCP, SNMP a há árom legelteerjedtebb. Mivel aaz UDP scan n lassabb éss nehezebb,, mint a TC CP, ezért né éhány bizton nsági szaké értő nem foglalko ozik ezekkell. Mivel a se ebezhető UD DP szolgálta atások gyak koriak, ezértt ez nagy hib ba. UDP sccan úgy műk ködik, hogy y küldünk eggy UDP cso omagot minden célporttra. Ha olya an ICMP csomagg jön vissza a, hogy portt unreachab ble, akkor a port zárv va van. Ameennyiben egy e UDP csomaggot kapunk vissza, v akko or a port nyiitva van. Ha a nem kapu unk vissza seemmit, akkor lehet, hogy nyyitva van, cssak a csoma agszűrők blo okkolják a kommuniká k ációt.
A hping (http://www.hping.org/) egy parancssori TCP/IP csomag összeállító/elemző eszköz. A felülete a ping parancshoz hasonló, de nem csak ICMP echo parancsok küldésére alkalmas, hanem TCP, UDP, ICM és nyers IP csomagok is küldhetőek vele. Tartalmaz továbbá egy traceroute módot és további funkciókat is. A hping a következő feladatok ellátására alkalmas: ●
Tűzfal tesztelés
●
Fejlett port szkennelés
●
Hálózattesztelés különböző protokollokkal, TOS, fragmentáció
●
Manuális útvonal MTU felfedezés
●
Fejlett traceroute az összes protokollra
●
Távoli OS ujjlenyomat készítés
●
Távoli uptime becslés
●
TCP/IP stack auditálás
●
A TCP/IP tanulásához bemutatóeszközként
A hping szkriptezhető tcl nyelven, példaként bemutatunk egy hping tcl scriptet, mely SYN flood támadást valósít meg: # (c) GPL2 fluxist(at)gmail.com # Usage; hping3 exec ./synflood.htcl if {$argc < 2} { puts "Required arguments: hostname dstport" exit 1 } foreach {hostname port} $argv break set srcport 14000 set target [hping resolve $hostname] set myaddr [hping outifa $target] puts "Synflooding $target..." while {1} { hping send "ip(saddr=$myaddr,daddr=$target)+tcp(sport=$srcport,dport=$por t,flags=s)" } Kimenet Az elküldött és fogadott csomagokat dumpolja a kért részletességgel. Gépileg is feldolgozható.
17
Előnyök A szkriptezhetőség
igen kitágítja a felhasználás lehetőségeit. Jól használható hálózati
protokollok implementációs hibáinak kutatására is. Hátrányok Igen alacsony szintű eszköz, elsősorban manuális használatra. Önmagában nem értékes automatizált környezetben, de mint építőkomponens a hálózati réteg sérülékenységeinek felfedezésében és kihasználásban használható automatákban.. Támogatott környezetek Unix-szerű operációs rendszereken képes futni: Linux, Solaris, OSX, stb. Költség GPLv2 alatt van kiadva, azaz szabadon felhasználható, de a módosítások forráskódját is GPLv2 alatt kell kiadni. Mivel önálló processzként fut, nem kell összelinkelni az integráció során, azaz integrálható zárt forrású szoftverrel is. Integrálhatóság Parancssorból és scriptekkel vezérelhető, a kimente gépi feldolgozásra alkalmas.
2.1.3. Nmap Az nmap egy ingyenes és nyílt forráskódú eszköz hálózati felderítéshez és biztonsági auditáláshoz. Nyers IP csomagok segítségével deríti fel a hálózaton elérhető eszközöket és többek között az azokon futó szolgáltatásokat (alkalmazás és verziója), és a rajtuk futó operációs rendszert.14 Eredmények értelmezése Az alábbi paranccsal indítsuk el nmap felderítésünket, ahol a scanme.nmap.org paraméter a célpontunk. # nmap scanme.nmap.org Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-09 18:07 CEST Források: http://en.wikibooks.org/wiki/Hacking/Tools/Network/Nmap, http://nmap.org/book/man.html#man-description 14
18
Nmap scan report for scanme.nmap.org (74.207.244.221) Host is up (0.19s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 9929/tcp open nping-echo Nmap done: 1 IP address (1 host up) scanned in 14.81 seconds Az nmap futásának eredménye egy lista a felderített célpontokról és az azokhoz tartozó információkról, a paraméterezéstől függően. Nekünk lényeges információ a port táblázatban található. Ez a táblázat portszámokat, azok állapotait, protokollokat és szolgáltatások neveit tartalmazza. A fenti példában azt látjuk, hogy a scanme.nmap.org célponton a 22, 80 és 9929-es portok vannak nyitva. A 22-esen egy ssh szerver figyel, a 80-ason egy http és a 9929-es porton egy nping-echo szolgáltatás fut. Paraméterek Az elérhető paramétereket és azok rövid leírását az nmap program paraméter nélküli meghívásával érhetjük el.15 Célpontok (Target specification) Célpontjaink lehetnek: ●
Host nevek ○ pl.: scanme.nmap.org
●
IP címek ○ pl.: 192.168.0.1
●
Hálózatok ○ pl.: microsoft.com/24
A következő kapcsolókat alkalmazhatjuk: ●
-iL : Célpontok listáját tartalmazó fájlt adhatunk így meg
●
-iR : Véletlenszerűen választ számú célpontot a megadottak közül
15
●
--exclude : Kihagyja a megadott célpontokat a vizsgálatból
●
--excludefile : Kihagyja a megadott fájlban található célpontokat a vizsgálatból
-sV: A nyitott portokon felderíti a szolgáltatásokat és azok verzióját
●
--version-intensity <szint>: 0-9 közötti port felderítési szintet lehet megadni (0: egyszerű, 9: minden próbálkozás)
●
--version-light: 2. szintnek felel meg, leggyakrabban működő módszerekkel próbálkozik
●
--version-all: 9. szintnek felel meg, minden módszert kipróbál
Operációs rendszer felderítés (OS detection) 1. -O: Operációs rendszer felderítés bekapcsolása 20
2. --osscan-limit: Szűkíti az operációs rendszer felderítését biztató célpontokra 3. --osscan-guess: Agresszívebben próbálja kitalálni az operációs rendszert Időzítés és sebesség (Timing and performance) Azoknál a paramétereknél, ahol van, alapesetben másodpercet adhatunk meg, de megadhatunk más értékeket is, ha az érték után odaírjuk az ms (milliszekundum), s (másodperc), m (perc) vagy h (óra) betűket (például: 30m). ●
-T<0-5>: Időzítő beállítása (minél nagyobb, annál gyorsabb)
●
--min-hostgroup/max-hostgroup
<méret>:
Párhuzamos
hosztok
vizsgálati
csoportjainak száma ●
--min-parallelism/max-parallelism <szám>: Párhuzamos próbák száma
--host-timeout : Célpontra ennyi ideig várunk, mielőtt feladnánk a vizsgálatát
●
--scan-delay/--max-scan-delay : Próbák közötti időt állíthatjuk ezzel
●
--min-rate <szám>: Minimum ennyi csomagot küldünk egy másodperc alatt
●
--max-rate <szám>: Maximum ennyi csomagot küldünk egy másodperc alatt
Tűzfal megkerülés és hamisítások (Firewall evasion and spoofing) ●
-f; --mtu <szám>: csomag darabok
●
-D : Vizsgálathoz csali használata
●
-S : Forrás cím hamisítása
●
-e <eszköz>: Eszköz meghatározása, amin keresztül küldjük a csomagokat
●
-g/--source-port <portszám>: Speciális port használata
●
--proxies
:
Kapcsolatok
HTTP/SOCKS4
proxy-kon
keresztüli
felépítése ●
--data-length <szám>: Véletlen adatok hozzáfűzése a csomagokhoz
●
--ttl <érték>: time-to-live mező beállítása
●
--spoof-mac <mac cím/prefix/gyártó neve>: Hamis MAC cím használata
●
--badsum: Csomagok hamis TCP/UDP/SCTP ellenőrző számmal való küldése
Kimenet (Output) 1. -oN/-oX/-oS/-oG : Vizsgálat eredményét normál formátumban, xml formátumban, szűrhető formátumba menti a megadott fájlba. 2. -oA : Három főbb formátumba menti ki a vizsgálat eredményét. 3. -v: Bőbeszédű kimenetet generál (-vv fokozza ezt). 4. --reason: Megindokolja a port állapotát. 5. --open: Csak a nyitott portokat mutatja. 21
6. --packet-trace: Minden csomagot mutat, amit küldött és fogadott. 7. --log-errors: Menti a hibákat a kimenetbe. 8. --resume : Leállított vizsgálatot folytat. 9. --stylesheet
<elérési
útvonal>:
XSL fájl
az XML fájl
HTML
fájllá való
konvertálásához. Egyéb (Misc) 1. -6: IPv6 vizsgálat engedélyezése 2. -A: Operációs rendszer felderítése, verziók felderítése, script felderítés, és csomagok útvonalának meghatározása. 3. -V: Nmap verziójának kiírása. 4. -h: Súgó kiírása. Zenmap Hivatalos grafikus felület az nmaphez. (http://nmap.org/zenmap/) 1. különböző profilok, pl.: a. slow comprehensive scan i.nmap -sS -sU -T4 -A -v -PE -PP -PS80,443 -PA3389 -PU40125 -PY -g 53 -script "default or (discovery and safe)" 10.0.0.24 2. Ezeket a profilokat használhatjuk a mi rendszerünkben is.
2.1.4. hostmap Leírás A hostmap egy szabad felhasználású eszköz hosztnevek és virtuális hosztok feltárására, mely Ruby-ban készült, szerzője Alessandro Tanasi, licensze a GNU General Public License version 3 (GPLv3). (https://github.com/jekil/hostmap) Az IP címek és a DNS bejegyzések dinamikusan kötődnek össze, a DNS célja a névfeloldás, tehát egy adott névhez tartozó IP cím megtalálása. Ugyanakkor egy adott IP-n több webszolgáltatás futhat, melyek teljes felsorolására a DNS nem ad lehetőséget. Ha ellenőrizni akarjuk egy webhoszt biztonságát, ismernünk kell valamennyi virtuális hosztot, melyet az adott szerver kiszolgál, hiszen az egyes virtuális hosztok mögött különböző szerver- vagy webszoftverek futhatnak, így azokon különböző támadási felületek érhetőek el. Ezt a problémát hivatott megoldani a hostmap eszköz, mely online szolgáltatások 22
igénybevételével keresi meg azokat a DNS bejegyzéseket, amelyek egy adott ip-re mutatnak. Ezek az online szolgáltatások különböző adatforrásokból dolgoznak, ezért várható, hogy különböző találatokat adnak, melyek uniója jól közelíti a valóságot. Ugyanakkor fontos látni, hogy technikailag nem megoldható, hogy valamennyi virtuális hosztot megtaláljuk, ugyanis a kiszolgált virtuális hosztok listája csak ás kizárólag a szerver konfigurációjától függ. Ha tehát egy virtuális hoszt, melyet a szerver kiszolgál, nincs rögzítve egy olyan adatbázisban sem, melyet elérünk, nem fogjuk megtalálni. A következő online szolgáltatások kerülnek felhasználásra: ●
Microsoft Bing
●
MIT GPG key server: http://pgp.mit.edu:11371
●
DNShistory: http://dnshistory.org
●
Domainsdb: http://www.domainsdb.net/
●
Gigablast: http://www.gigablast.com
●
Netcraft: http://searchdns.netcraft.com
●
Robtex: http://www.robtex.com
●
Tomdns: http://www.tomdns.net
●
Web-max: http://www.web-max.ca
23
Előnyö ök ●
Mivel több forrásból dolgozik, d az eredmény teljesebb. t
●
A cli felülett hatékonya abban kezelh hető, mint az a online szolgáltatásokk webes felü ületei.
●
Gyors, több bszálú műkö ödés
●
Többféle feelfedezési sttratégia érh hető el, ezek k függetlenü ül ki- és bekkapcsolható óak. (pl. dns host brrute-force, zone z transfeer check, stb b.)
nyok Hátrán ●
Online szollgáltatásoka at használ, aazoktól függ g a működé ése. Ez mind d licenszelési, mind teljesítmén ny
szempo ontból
pro oblémás,
ha h
autom matizált
köörnyezetben n
kerül
felhasználá ásra. net Kimen ●
Szöveges lissta a konzollra
●
Maltego XM ML formátu um
gatott körn nyezetek Támog ●
Bármely kö örnyezet, ah hol Ruby eléérhető.
24
Költség ●
GPL licenszelt, tehát ingyenesen felhasználható. Független eszközként használva nem kell
összelinkelni
a
nem-GPL
kódokkal,
tehát
alkalmazható
zárt
forrású
rendszerekben is. Azonban ha a forráskódja módosításra kerül, úgy a módosított kódot publikálni kell. Integrálhatóság ●
CLI-ből paraméterezhető
●
A szöveges kimenet könnyen felolvasható, a fejlécet kell kiszűrni.
●
Az XML kimenet kifejezetten gépi feldolgozásra készül
Tehát az eszköz egyszerűen integrálható.
2.1.5. hoppy Leírás A hoppy (https://labs.portcullis.co.uk/tools/hoppy/) egy python script a HTTP opciók vizsgálatára és információszivárgás felfedezésére. A hoppy betűszó: http options prober written in python. Az eszköz megvizsgálja az HTTP metódusok elérhetőségét és megvizsgálja őket, hogy segítségükkel előidézhető-e információszivárgás. Funkciói: ●
HTTP Method detektálás TRACK, TRACE, PUT stb.
●
Belső IP cím szivárgásának keresése
●
Belső Path szivárgás keresése
●
Adatkinyerés
●
Spider funkció alkönyvtárak keresésére, és webDAV ellenőrzés
●
ms09-020 IIS auth bypass ellenőrzés a felfedezett könyvtárakon
Az eszköz lelke a “http-methods” fájl, amiben fel vannak sorolva az elvégzendő tesztek. A fájl bővítésével újabb tesztek fogalmazhatóak meg. A fájl formátuma a következő: # # # # # # #
method_name, interesting_resp_code, send_to_server (host) will be replaced by the hostname (port) will be replace by the port (location) will be replace by (location) to test with webDAV (file) will be replace by file to test with webDAV (wait) will cause the client to wait for a server respose 25
i.e. 100 Continue # (auth) will be replaced by the basic auth credentials if supplied # (loop) will be replaced in a loop with all entries in the loop file # (cookie) will be replaced by the cookies passed to hoppy Egy példa, érvénytelen http metódus, mely minden megtalált könyvtárra be lesz küldve: Invalid Method, X, HOPPY (location)/ HTTP/1.1\nHost: (host)\n(cookie)\n(auth)\n\n Előnyök ●
Egyszerű használat
●
Jó paraméterezhetőség
●
Könnyű bővíthetőség új tesztekkel
Hátrányok ●
Kevés funkció
●
Hiányzik a szervertől érkező nem standard válaszok megfelelő kezelése, ezért nagy a false pozitív veszély
Kimenet Fájlba vagy kimenetre irányítható, tartalmazza a műveletek és az elvégzett vizsgálatok logjait és eredményüket, a scan végeztével egy összefoglalót a megtalált könyvtárakról, azok webDAV eléréséről és a felfedezett információkról, valamint teljes dump is kérhető manuális ellenőrzéshez. [+] Information Leakage: Location: http://battletac.com/web/guest;jsessionid=751A1E029F3E46E898E8 A52A26794F36 Location: http://battletac.com/web/guest;jsessionid=94E91731C67DDC83E2E2 AF924F40AD13 Location: http://battletac.com/web/guest;jsessionid=BCFC425120ABEBA58808 8F301912F362 MicrosoftSharePointTeamServices: 6.0.2.8117 Public-Extension: http://schemas.microsoft.com/repl-2 Server: Apache/2.2.22 (Ubuntu) Vary: Accept-Encoding Apache/2.2.22 (Ubuntu) Server at tdrcxam.com Port 80 Apache Tomcat/6.0.18 Error report<style>
