Az előző postban elszöszöltünk az IPoptions RR/TS -el, TTL-el, és többnyire csak TCPvel foglalkoztunk. Ez a post egy kicsit támaszkodni fog rá, szóval ha még nem olvastad akkor célszerű először azt. Igyekszek lényegretörően felépíteni az írást, de most sem megyek le nagyon a részletekig. Maradunk továbbra is a 3. és 4.-ik layeren. Se fel, se le... egyelőre.

Most két olyan témát fogunk kapirgálni, amelyeket csak egymás mellett érdemes tárgyalni: scannelés és tűzfalak. Eredetileg ezt a két témát egy postban szerettem volna lezavarni, de elég hosszúra sikerült, ezért utólag kettészedtem, úgyhogy a harmadik epizód már be van tárazva.

Fontos kérdés: Mit nevezünk tűzfalnak? Noss.. ez csak attól függ hogy kit kérdezel. Enterprise környezetben nem tűzfal az, ami alkalmazásszinten nem véd. Értsd: szűri a HTTP forgalmat, IM protokollokat csesztet, vírusokat kerget, ésatöbbi blaa blaa blaa... Madár ellen kerítés. Amikor szóba kerülnek akkor kicsit nyűgös leszek, aminek történelmi okai vannak. (Tudom... velem van a baj, mert ezek nagyon kiforrott termékek.) Na ezekről nem lesz szó, vagyis csak max layer4-ig. Amikor azt mondom tűzfal, csomagszűrő tűzfalról beszélek, de ezek sem egyformák. Mit szeretnénk (meg)tudni róla? A network stack implementációja mennyire komplett? Stateful/stateless? Azon a vason fut ahol a szolgáltatás vagy előtte? Milyen szabályok vannak rajta felvéve? Tudom bypassolni őket?

A scannelés az információgyűjtés aktív fázisának a része, az egyik legfontosabb módszer a támadó eszköztárában a célhálózat feltérképezésére. A támadónak van egy célja, és ehhez keresi az utat. Ehhez kell a jó térkép. Egy átfogó scan magába foglal host-, service- és OS-detection-t, képet ad a hálózati topológiáról, a használt technológiákról, tűzfalakról. Végeredményben a tesztelés további fázisainak ez lesz az alapja.

Lássuk.

Scannelés

Nmap, unicornscan, hp scanjet g2710, etc... kinek mi a kedvenc scannere, én az nmapot kedvelem bcoz of reasons, de ennek is megvannak a korlátai sajnos. Csak hogy ne legyen se totál broken a mondókám, se túl leveses, nézzük meg a basic módszereket. Igyekszem rövidre fogni.

Host detection

A szokványos megoldások mint a ICMP/timestamp echo request, tcp common port próbák mind arra irányulnak hogy mindegy milyen packet, csak válaszoljon. Ezeket most hagyjuk, nem sok tárgyalni való van rajtuk. közelítsük meg más irányból.

Inverse mapping

A módszer lényege abban áll, hogy elküldünk egy adag ICMP echo reply-t (nem typo) a célzott háló irányába. Mivel a router nem trackeli az ICMP echo requesteket, ezért a replyt tovább dobja a címzetteknek, már akiről tud. Ha valakit nem ismer akkor visszaküld nekünk egy ICMP Host unreachable-t. Ebből nem fogjuk látni hogy kik vannak, viszont azt igen, hogy kik nincsenek: ebből lehet következtetni arra hogy kik vannak. Még ha tűzfal is van a háló előtt, jó sansz van rá hogy ebbe nem szól bele.

UDP scan

(Utálatos, fuj fuj fuj) Essünk túl rajta. Két metódus létezik: Küldesz paketot, és ha nem listenel ott semmi és mákod van akkor kapsz egy ICMP/portunreachable -t, és akkor is csak nagyon lassan lehet scannelni mert az ICMP hibaüzenetek néhány típusa alapból rate limitelve van linuxnál. Bővebben: man 7 icmp. Windowsnál a stock tűzfal megeszi a icmpunreach-eket. Nmap-nál igen hasznos feature a --reason, így látni fogjuk hogy miért mondja azt amit.

A másik lehetőség a sweep scan. Megpróbál valid paketokat küldeni az egyes szolgáltatásokra és vár a válaszra. Az nmap a -sUV -ra csinál ilyet, és kb 20 különféle servicera van patternje. Ez sajna úgy működik hogy először scannel egyet az első módszer szerint, és ami portot open vagy open|filtered -nek gondol oda elküldi a megfelelő stuffot, aztán figyel... ha nincs icmp unreach, és sok az open|filter akkor mocskos lassú. A Nessus is tud ilyet, sokkal több servicet ismer (~70-80), viszont cserébe ez is mocskos lassú. A Metasploit udp_sweep modulja elég gyors, viszont cserébe csak 10-12 servicet vág, és nem is nézi a többi portot, csak a defaultokat. Az Unicornscan is elég hatékony (értsd: ki lehet várni) a -mU kapcsolóval (és --pps 200 az úgy korrekt packet/sec ha /24-et scannelsz, mert inkrementálva megy körbe az IPken), így egy default portlistát pörget. Itt van még egy témába vágó post Carnal0wnage-en, itt is van pár jó tipp.

TCP scan

Alapvetően nem szeretnék végigklaffogni az nmap beépített TCP scan technikáin, egyrészt mert arra ott van a man (+ egy halom írás, tutorial), másrészt meg ez egy tech blog, nem CEH előkészítő. Végül arra jutottam hogy inkább a működési mechanizmusokat és a módszertant érdemes megvizsgálni.

Mielőtt ennek nekiesünk, vizsgáljuk meg a működési mechanizmust. Ha útnak eresztesz egy paketot akkor vagy jön válasz, vagy nem jön válasz. Ha jön válasz akkor az 4 módon történhet: SYN+ACK, RST, RST+ACK, illetve ICMP hibaüzi. Most csak a flagekre koncentrálunk, és ezekből is a SYN, ACK, és RST ami egyelőre érdekes.

1. Ha az RST flag be van állítva, akkor azt minden egészséges network stackkel szerelt OSnek el kéne dobnia (akár open, akár closed), ettől eltérő viselkedés esetén joggal feltételezhetjük a tűzfal appliance jelenlétét. Ugyanez az incomplete-network-stack jelenlét megfogható azzal is, ha inkorrekt TCP/UDP checksummal küldött paketra jön válasz. Az nmap a --badsum kapcsolóval tudja így elcseszni a layer4-et. Erről a módszerről bővebben a Phrack 60/12 -ben
2. Az ACK-et bármilyen más flaggel kombinálva (kivéve RST) egy pucér RST -t kell kapnunk, akár open, akár closed a port. Ha nem kapunk semmit akkor filtered, ha mást kapunk akkor az vmi tűzfal.
3. Ha SYN paketot küldesz, az ACK és RST kivételével bármilyen más flaggel kombóban, akkor SYN+ACK-ot kapsz nyitott portra, RST+ACK -ot zárt portra. Eltérő viselkedés esetén tűzfal van.

Ezt így lehet általánosítani, de ha az igaz szamurájok útját választod akkor az RFC793 legyen a mestered. A 64-edik oldalon találod a CLOSED és a LISTEN state-re vonatkozó viselkedéseket. 

intermezzo

Említettem hogy az nmapot kedvelem (a korlátaival együtt). Az egyik ami miatt kényelmetlen a használata az az, hogy a response packetok részleteit nem írja ki alapból. Pl. ahoz hogy a TTL-t is lássam --packet-trace -el kell indítani. Azóta se értem. Az Unicornscan bezzeg kiirja. Meg a hping3 is, tök kulturált jól átlátható kimenetet ad, és jól paraméterezhető, de én inkább tűzfal teszteléshez szeretem... ízlés kérdése. Nem célom összehasonlítani hogy melyik scanner/tool mit tud és mit nem. Az nmap nem mutatja a fontos kis részleteket, a hping3 nem tud tartományt scannelni, az unicorn scannél nem lehet állítgatni a scanflageket, se fragmentálni se tud.

A helyzet az hogy mindegyiknek megvannak az előnyei, korlátai, neked pedig adott a választás lehetősége. Ha nem vagy elégedett, írhatsz sajátot, és ha aktívan teszteléssel foglalkozol, akkor előbb utóbb rájössz hogy lehet, és célszerű automatizálni egyes vizsgálatokat/feladatokat. Így születnek a jó toolok. :)

Na de vissza a parkettre. (még a TCP scannél tartunk :))

/intermezzo

Most csak a FW evasionre és ruleset mappingra zoomolunk. Egyrészt lehet a flagekkel görénykedni, másrészt minden mással. Nézzük a flageket:

A legtöbb free, és kereskedelmi forgalomban kapható tűzfal és IDS csutka nélkül levág egy stock nmap SYN scant. Jó esetben csak generálódik egy alert, és bekerülünk a nap végi összefoglalóba amit az admin megkap emailben. Ha nincs szerencse akkor IP alapján kivágnak minket, és esetleg még egy abuse@ is útnak indul a szolgáltatónk irányába. Erre jelenthet megoldást az nmap --data-length paramétere, és a különféle flagekkel való scannelés. Ja és az okos timing... SYN scan nyugíjas tempóban, az a tuti. Nem kell kapkodni, mindig legyen időd rendesen reggelizni és kávézni.

Azt hogy bejátszik egy tűzfal, általában nehéz nem észrevenni. Ha már sikerült kideríteni hogy egy tűzfal belekotnyeleskedik a dolgunkba akkor érdemes megvizsgálni ACK paketokkal. Első ránézésre furcsának tűnhet, hiszen mindegy hogy listenel-e a port vagy nem, mindenképpen RST-t kapunk vissza. Kivéve ha stateful tűzfalba ütközik, mert ha az trackeli a kapcsolatokat akkor nem fogja átengedni... de a FIN scant se.

Egyelőre ennyit a flagekről. Az a legjobb ha eljátszol a különböző tűzfalakkal, zsonglőrködsz a flagekkel, megfigyeled és kitapasztalod a viselkedéseket. Az nmapnál szerencsére a --scanflags opcióval lehet variálni a tcp portscanhez használt flageket, ami a --reason kombinációjával jó szolgálatot tesz amikor valami másra van szükségünk mint a bedrótozott scan technikák.

Az alternatív scan technikák közül megemlíteném a Maimon scant. A technikát Uriel Maimon publikálta a Phrack 49-15 -ben 1996-ban, és az nmapba is belekerült (lásd Fyodor Phrack 51-11) a FIN scan (-U kapcsolóval, mint Uriel). Az eredeti cikk címe "Portscanelés SYN flag nélkül", és erre két metódust ír le: Az egyik a BSD netcode azon sajátosságát használja fel, miszerint a listen porton elnyeli a FIN csomagot. Igen ez pontosan a FIN scan. A másik módszer az ACK scan (az ACK-ra ugye minden esetben RST-t kapunk), ami arra alapul(t) hogy a visszakapott RST paket TTL-je eggyel alacsonyabb volt nyitott portnál mint zártnál, ráadásul a window méret sem volt a zárt portnál megszokott nulla.

Ehez képest most a Maimon scan nmapban FIN+ACK paketokkal szemetel, amiről szó nincsen az egész cikkben, és a mellékelt kód sem tartalmaz ilyet. Valaki félreértette ezt a mondatot...

"I use TCP packets with the ACK, and FIN flags turned on.".

Hunger talált nekem egy ilyen őslényt (horus.icbm.uni-oldenburg.de) amin demonstrálható a módszer. Köszi! :) Bevallom most látok először ilyet. Sajnos az nmap Maimon scan implementációja nem működik, ezért egy saját scripttel nézem:

# ./porttest 134.106.80.130 21-23 S
port | flags | ttl | win   | seq
21   | SA    | 45  | 32768 | 372454725
22   | RA    | 45  | 0     | 0
23   | SA    | 45  | 32768 | 372607376

# ./porttest 134.106.80.130 21-23 A
port | flags | ttl | win   | seq
21   | R     | 45  | 32768 | 0
22   | R     | 45  | 0     | 0
23   | R     | 45  | 32768 | 0

Menet közben átgázoltunk egy ezidáig nem említett kifejezésen miszerint "window méret", de hogy jön ez képbe a portscannelésnél? Ez nem biztos hogy mindenkinek kerek, úgyhogy tegyünk egy kis kalandos kitérőt flow control földére, de ha vágod akkor GOTO 10;

A TCP window a flow control eszköze (ezt hogy mondják magyarul?). Gondolj rá úgy mint receive buffer. A kapcsolat kiépülésétől kezdve minden egyes ACK csomagnál be van állítva a window méret, ami tudatja a fogadó féllel hogy max mekkora cuccost bír el a recv buffere. A küldő félnek max ekkorát illik küldenie. Ha a fogadó fél nem tudja elég gyorsan olvasni (/feldolgozni) az adatokat, a recv buffer megtelik. Ilyenkor az OS küld egy paketot nullás window mérettel. A küldő fél ilyenkor általában elkezd (wiresharkos nyelvezettel élve) ZeroWindowProbe -okat küldeni amire ZeroWindowProbeAck a válasz. Ebből tudja a küldő hogy a túloldalon még valami küszködés van. Amikor a fogadó félnek sikerült utolérnie magát, akkor küld egy ACK-t az aktuális window mérettel, ezt hívják úgy hogy TCP window update. De egyelőre ennyit erről.

10

Na de hogy jön ez képbe scannelés közben? Amikor szembejön egy SYN+ACK csak éppen nullás window mérettel...

# ./porttest [furcsa_weboldal_IPje] 80 S
port | flags | ttl | win   | seq
80   | SA    | 62  | 0     | 2593461280


...akkor jusson eszedbe hogy bizonyos loadbalancerek és tűzfalmegoldások tweakelnek ilyen furmányos módon. Ha látsz egy ilyet (RST+SYN -re SYN+ACK)...

# ./porttest [furcsa_weboldal_IPje] 80 SRA
port | flags | ttl | win   | seq
80   | SA    | 62  | 0     | 4137744821


...akkor sem kell meglepődni, van ilyen csúnyán broken network modul. Na de hagyjuk az aberrált példákat, tesztelések közben fogsz találkozni pár furcsasággal. Az ilyen kisebb teszteket is célszerű automatizálni ha sokat használjuk: Ha megfuzzoljuk a flageket, elég könnyen ki lehet szúrni a rendellenességeket. Van 6 bit amit végig lehet pörgetni, 64 testcase nem sok. De többnyire fölösleges, elég csak SYN, ACK, FIN, és esetleg az RST flageket megforgatni.

# ./TCPFlagFuzzer example.com 80
ICMP:
  SA: S
   R:
  RA: N F A FA SA


vagy:

# ./TCPFlagFuzzer.ext example.com 80
flags_out | flags | ttl |     win |        seq
N         |    RA | 246 |       0 |          0
F         |    RA | 246 |       0 |          0
S         |    SA | 246 |    1608 | 1705425240
P         |    RA | 246 |       0 |          0
FP        |    RA | 246 |       0 |          0
SP        |    SA | 246 |    1608 | 1813841261
A         |    RA | 246 |       0 |          0
FA        |    RA | 246 |       0 |          0
SA        |    RA | 246 |       0 |          0
PA        |    RA | 246 |       0 |          0
FPA       |    RA | 246 |       0 |          0
SPA       |    RA | 246 |       0 |          0
U         |    RA | 246 |       0 |          0
FU        |    RA | 246 |       0 |          0
SU        |    SA | 246 |    1608 |  819784110
PU        |    RA | 246 |       0 |          0
FPU       |    RA | 246 |       0 |          0
SPU       |    SA | 246 |    1608 | 2274254500
AU        |    RA | 246 |       0 |          0
FAU       |    RA | 246 |       0 |          0
SAU       |    RA | 246 |       0 |          0
PAU       |    RA | 246 |       0 |          0
FPAU      |    RA | 246 |       0 |          0
SPAU      |    RA | 246 |       0 |          0
finished

Ezzel szépen lassan alácsúsztunk a tűzfalaknak. Nézzünk szembe a kegyetlen valósággal: a tűzfal azért van hogy keresztbe tegyen a játékunknak. Egy tisztességesen beállított tűzfalat bypassolni majdnem lehetetlen.

Nem véletlenül van ott az a "majdnem" kiemelve. Egy kis hacker szemlélet: Soha, de SOHA ne mondd azt hogy lehetetlen. Amikor kimondod hogy lehetetlen, bezártad az ajtót, és nem fogod rajta tovább törni a fejed, nem vizsgálsz meg több lehetőséget. Lehet hogy nem fog sikerülni, de ha meg sem próbálod, akkor biztos hogy nem fog sikerülni. ez gyakran megesik. ^___^

Két security model van, a pozitív és a negatív. A pozitív azt mondja hogy mindent tiltunk, és explicit azt engedjük amit akarunk. A negatív azt mondja: mindent engedünk, de tiltjuk amit nem szabad. Egy default drop policy viszonylag könnyen azonosítható hiszen minden filtered, kivéve amit engednek. Egy defaultaccept/tiltunk-ezt-azt esetében a portok nagy többsége closed lesz. Nmap synscannél ez így néz ki:

Not shown: 119 filtered ports
Reason: 119 no-responses
PORT   STATE SERVICE REASON
80/tcp open  http    syn-ack

Not shown: 55 closed ports
Reason: 55 resets
PORT   STATE SERVICE REASON
80/tcp open  http    syn-ack


Persze hogy nem lehet általánosítani így, hiszen vannak hazudós tűzfalak. Az hogy a port closed annyit tesz hogy kaptunk egy RST+ACK-t, de egyáltalán nem biztos hogy a szerver mondja. Viszont ha a tűzfal válaszol akkor egész jó sansza van hogy a TTL különbözni fog, erre nem szoktak odafigyelni. A flagfuzzer egy hasznos jószág, érdemes ráfuttatni nyitott, zárt, és filterezett portokra is.

Bár a fal jelenlétének igazolása általában megoldható különböző scanekkel, de blackboxból felmappelni a rulokat már túlmutat a stock scanek lehetőségein. A nyitott portokon meg lehet vizsgálni a kapcsolat felépítésétől a lezárásig különféle rfc incompliant vagy épp compliant-csak-szokatlan manővereket. Lehet fejtegetni a szabályok feltérképezését, próba-kizárás alapon egész jól meg lehet közelíteni az valóságot. Ez a topic most kimarad, kevésbé érdekes mint az, hogy hogyan lehet bypassolni azt a nyavalyás tűzfalat ami mögött vár a loot. Amúgyis erre megy ki az egész. Itt van az a pont ahol kettévágtam a postot.

Bár már itt is kóstolgattuk, de a következő post jobban a tűzfalakra fog fókuszálni, de visszatérünk még egy pár gondolat erejéig a scanneléshez is.