Nyni pocitame s tim, ze klient pristupuje k webu pres segmnent, ktery mame
pod kontrolou - treba pres nas proxy server. Nami drive vygenerovanou
cookies mu podsuneme, pokud se prihlasi k nezasifrovane verzi webu,
pripadne ji podsuneme treba jako vlozeny obrazek do jine webove stranky,
v extremnim pripade muzeme nahodny pozadavek klienta presmerovat na
nesifrovanou verzi webu. K tomuto ucelu nam poslouzi tzv. filtrovaci proxy
servery, treba Privoxy apod.

/---------                              /-------                   /---------

| Browser |-<-- nam zname Session ID -<--| Proxy |---------<---------| Server  |

---------/                              -------/                   ---------/

Nyni ma klient v prohlizeci ulozenou cookie s nami vygenerovanym Session ID.
Protoze vetsina skriptu funguje tak, ze kontroluje, jestli mate pridelenou
nejakou session, a pokud ne vygeneruje dalsi, tak nam toto webovy server
pohodlne prijme. Server nebude mit tuseni, ze se prihlasuje nyni nekdo zcela
jiny, jednoduse s vygenerovanou cookie svaze nove uzivatelske jmeno a heslo
(to ovsem nelze ziskat, protoze je ulozeno na serveru, a je vazano pouze na
session id) a oznaci vasi session za prijatou. V tomto pripade jste se vy
uspesne prihlasili k serveru pres sifrovane spojeni a presto zna utocnik
vase Session ID, ktere mu umozni delat operace primo pod vasim jmenem.
Nyni staci utocnikovi v prohlizeci zadat pouze internetovou stranku sluzby a
bude automaticky prihlasen. Pokud navic cely utok probehne presmerovanim
pres proxy server, nezmeni se ani IP adresa pocitace a vse tak bude vypadat,
jako by dane operace provadela opravnena osoba.

/---------                              /-------                   /---------

| Browser |--->-----SSL--------------->--| Proxy |---SSL--->---------| Server  |

| SID:100 |                     /        | IP:A  |                   ---------/

---------/                    /         -------/

                              /

                             /

/---------                 /

| Utocnik |--->-----SSL----/

| SID:100 |

---------/

Prakticke realizace utoku

1) Sezeneme si filtrovaci proxy server - treba privoxy (linux),
proxomitron (win32)

2) Vygenerujeme si Session ID

3) V proxy serveru pridame do hlavicek nezasifrovaneho spojeni nami
vygenerovanou Session ID

4) Nejakym zpusobem osobu dostaneme na nezapezpecene stranky, treba pres
301 redirect, vlozenim skryteho obrazku atd...

5) Pokud uvidime SSL aktivitu na port 443, jenom zadame adresu pro prihlaseni
a automaticky budeme systemem prihlaseni

6) Enjoy :-)

Obrana proti utoku

1) U vsech cookies pouzivanych u sifrovaneho spojeni pouzivejte priznak
Secure

2) Cookies generujte az po uspesnem prihlaseni

3) Pred prihlasenim zahazujte cookies

Aplikovatelnost utoku

Pres 60% sluzeb pristupnych s SSL.

Fry, fry (zavinac) hysteria (bodka) sk

Tyto udaje nejsou z pochopitelnych duvodu kompletni, zaslouzily
by si samostatny clanek. V IT oblasti se nejcasteji pouziva
infracervene a cervene pasmo. Vyjimkou je WDML, ktere pouziva
ruzne casti spektra pro zajisteni vysokych datovych toku.
Ostatni vlnove delky se pouzivaji v jinych aplikacich
(lekarstvi, fyzikalni a chemicke experimenty, merici sondy
atd.). Protoze nemam prostredky, tezko si budu hrat s
odposlechem WDML, teoreticky by to slo pomoci hranolu a nekolika
cocek. Vysledek by byl ovsem znacne slozity, podstatne
slozitejsi nez stavajici zarizeni. Dalsi tabulka uvadi prehled
zarizeni pro generovani laserovych signalu male intenzity pro
prenosy dat v libovolnych aplikacich.

Frekvencne je deleni nasledujici:

Vlnova delka v nm       Typ laseru       Utlum signalu

1550                    LED              0.050

1300                    LED              0.030

1064                    ND:YAG           0.012

850                     LED              0.013

820                     LED              0.006

647                     Krypton Red      0.008

633                     HeNe             0.008

532                     KTP              0.013

515                     Argon Green      0.014

488                     Argon Blue       0.013

308                     Excimer          0.27

248                     Krypton Fluoride 1.1

c=299 987 762.254 372 ms-1

P.S.: Optika je velice narocna na presnost. Jak jsem zjistil uz
pri prvnim pokusu - staci malo ;o)

Derelict, derelict (zavinac) hysteria (bodka) sk

Este komentar k vasim popisom:

WOODY

var     heslo:string;

        p:integer;

        act:char;

        ok:boolean;



Begin

        heslo:='11221013..';

        p:=0;

        ok:=boolean;

	

...RANO X-8

(BROKEN PIPE -/)_



Segmentationj fault

woody@lacey:#init0

Z uvedeneho vidno, ze sa mu zlamala pipeline a zlyhal rozdelovac,
takze mu to nezapalovalo.

V92/NIEKT0

Zle zapisane heslo, smola. Postup je pre nezasveteneho maximalnou zahadou.
Ako a voci comu merat? Co mam hladat?

REJDEN

Az v nedelu dal kratky popis, ale dolezity v duchu "Doveruj, ale preveruj
(aj kable)"

SVEN

Postup zahrnul do troch bodov a vela dolezitych udajov o implementacii zamku.

FRY

Popis sa dal pochopit, aj ked vyzaduje vlastnu iniciativu citatela.

CAHA

Podobne, keby tam bol nakreslil obrazok, mal by aspon o bod viac.

NIEKT0 (cheatujuci)

Ako jediny spomina, ze obvod ma aj nespecifikovany timeout pri zadavani.
Celkom podareny popis postupu, len tak dalej.

ZVIRATKO

Dobre uvadza, ze tam niekde je cosi, co urcuje poradie.

SEBA/CAHA/MIKE

Ich popis vhodne doplna popis Niekt0ho, popisuje tiez kde je zrada v obvode.

Vysledky ucastnikov, bodovanie:

LEVEL1                  OPEN    CODE    POSTUP  SPOLU

v92/niekt0              6       1       1.5     8

rejden                  6       7       2       15

sven                    6       7       4       17

fry                     0       0       2       2

stanojr                 0       0       0       0

zviratko                0       0       2.6     3

caha                    6       7       1.5     14

WooDy/pajkus/alik       6       7       1.5     14



LEVEL2                  OPEN    CODE    POSTUP  SPOLU

WooDy                   6       7       3       16

niekt0(cheatujuci)      6       6       4       16

seba/caha/mike          6       7       4       17

Oniko, oniko (zavinac) hysteria (bodka) sk

Vsetky data, ktore posiela pocitac PC-a pocitacu PC-b, posle hub aj pocitacu
PC-c. To, ci prislusny paket pocitac spracuje, zavisi od IP adresy prijimatela
a pocitaca, ktoremu paket prisiel. Kedze kazdy pocitac ma inu IP adresu,
ziaden pocitac nespracuvava cudzie data.

Sietovu kartu je vsak mozne prepnut do tzv. promiskuitneho rezimu, kedy karta
prijima vsetky pakety bez ohladu na to, komu boli adresovane. Pokial pocitac
PC-a je server, PC-b je uzivatel a PC-c je utocnik, staci utocnikovi prepnut
kartu do promiskuitneho rezimu a dokaze odchytit
vsetky data (mena, hesla, maily,
...) ktore posielal uzivatel serveru (PC-a -> PC-b) alebo server
uzivatelovi (PC-b -> PC-a).

Okrem slabej bezpecnosti sa hub vyznacuje slabou priepustnostou. Ked mame do
10 Mb hubu zapojenych 8 uzivatelov (PC-a, PC-b, ... PC-g, PC-h), ktore si
navzajom vymienaju data (PC-a "iba" s PC-b, PC-c "iba" s PC-d, ...), vsetkym
styrom dvojiciam ide prenos max. 2.5 Mb.

Narozdiel od hubu, switch je "inteligentnejsi". Pokial pocitac PC-a posle
paket pre pocitac PC-b, paket je poslany iba pocitacu PC-b. Tym sa zvysila
priepustnost medzi jednotlivymi pocitacmi zapojenymi do swichu a navyse
utocnik pocuvajuci na pocitaci PC-c sa nedostane k datam, ktore prudia medzi
pocitacom PC-a a PC-b. I ked ma kartu v promiskuitnom rezime, neodchyti nic
(okrem svojich paketov a par "broadcastov"), lebo pakety sa nedostanu na jeho
kabel. Teda pokial im k tomu nepomoze... ;]

Teraz trochu teorie, ako pracuje switch. Kazdy pocitac ma svoju IP adresu.
Okrem IP adresy ma kazda sietova karta svoju jedinecnu MAC adresu. MAC adresa
je 48 bitov dlha jedinecna adresa, ktora je vyrobcom 'napalena' do kazdej
sietovej karty. Niektore ovladace umoznuju softwarovo tuto adresu menit, jedna
sa vsak o softwarovu zmenu a zaznam vo flash zostava nezmeneny.

Vo vseobecnosti, MAC adresy su pouzivane na 2. vrstve zatial co IP adresy su
pouzivane na 3. vrstve. Niekto by sa mohol spytat, naco su MAC adresy, ked
stacia IP adresy. Odpoved je jednoducha, IP adresy su sucastou IBA protokolu
IP, zatialco MAC adresy su o vrstvu nizsie, cize su pouzitelne aj pri inych
protokoloch. Pri IPX/SPX komunikacii neexistuju IP adresy, ale MAC ano.

A prave na zaklade tychto MAC adries switch rozlisuje, komu posle ktore data.
Switch ma vlastnu tabulku, ktora MAC adresa sa nachadza na ktorom porte.
Taka tabulka moze vyzerat napr. takto:

port 1: aa-aa-aa-aa-aa-aa

port 2: bb-bb-bb-bb-bb-bb

port 3: cc-cc-cc-cc-cc-cc

(predpokladame, ze PC-a ma MAC adresu aa-aa-aa-aa-aa-aa,
PC-b bb-bb-bb-bb-bb-bb, ...)

Ked posle PC-a paket pre PC-b, switch skontroluje cielovu MAC adresu
(bb-bb-bb-bb-bb-bb) s tabulkou a posle to na port 2.

Ako vsak moze PC-a vediet MAC adresu PC-b? Predpokladame, ze PC-a vie IP
adresu PC-b. Na zistenie MAC adresy z IP adresy sluzi tzv. ARP protokol.
PC-a vysle ARP paket, ktory obsahuje nieco ako otazku: "Tu PC-a s MAC adresou
aa-aa-aa-aa-aa-aa, hladam PC-b, aku mas MAC adresu?". Tento paket posle na MAC
adresu ff-ff-ff-ff-ff-ff (broadcast) a switch ho rozposle na vsetky porty.
(Ano, tento paket moze utocnik na PC-c odchytit, ale je mu nanic). PC-b z ARP
paketu vie MAC adresu PC-a, odpovie mu so svojou MAC adresou a uz komunikuju...

Moznosti utoku:

MAC flooding:

Switch si tabulku MAC adries vytvara podla zdrojovej MAC adresy. Ak utocnik
vysle vhodny paket, switch si bude mysliet, ze pocitac s MAC adresou
bb-bb-bb-bb-bb-bb sa nachadza na porte 3, upravi svoju tabulku a vsetky data,
ktore bude posielat pocitac PC-a pocitacu PC-b sa dostanu k pocitacu PC-c.
Toto bude fungovat, pokial pocitac PC-b nevysle daky paket a switch si nezmeni
tabulku naspet. Pokial budeme 'falosne' pakety posielat dostatocne casto,
switch usudi, ze nevie, kde je pocitac s mac adresou bb-bb-bb-bb-bb-bb a bude
fungovat ako hub. Tato technika funguje iba na niektorych switchoch a vzhladom
na velky pocet potrebnych falosnych ARP paketov je aj lahko detekovatelna.
Ja osobne som tuto techniku neskusal, nakolko nasledujuca sa mi zda vhodnejsia
a elegantnejsia.

ARP poisoning:

Pointa tejto techniky spociva v myslienke presvedcit pocitac PC-a, ze pocitac
PC-b ma mac adresu cc-cc-cc-cc-cc-cc. Vtedy vsetky data, ktore bude chciet
poslat pocitac PC-a pocitacu PC-b prijdu pocitacu PC-c. Samozrejme je potrebne,
aby PC-c nasledne preposlal vsetky pakety pocitacu PC-b, inac by sa zrusili
vsetky spojenia. Takymto sposobom dokaze utocnik pakety nie len odchytavat,
ale dokaze ich aj modifikovat (tzv. man in the middle), co je z hladiska
bezpecnosti este vacsie riziko, ako "iba" sniffovanie.

Sposob ako presvedcit pocitac PC-a, ze pocitac PC-b ma mac adresu
cc-cc-cc-cc-cc-cc je jednoduchy. Staci mu poslat 'spoofnutu' ARP odpoved,
kde 'akoze' PC-b oznamuje pocitacu PC-a, ze jeho mac adresa je
cc-cc-cc-cc-cc-cc. Rovnakym postupom dokaze 'presvedcit' pocitac PC-b, ze
pocitac PC-a ma mac adresu cc-cc-cc-cc-cc-cc a tym dokaze odchytavat (ak bude
chciet aj modifikovat) vsetku komunikaciu medzi PC-a a PC-b. Zaznamy v ARP
tabulkach vsak maju obmedzenu casovu platnost. Ak sa dlhsiu dobu PC-a
nekomunikuje s PC-b, vymaze zaznam o MAC adrese. Pri naslednom pokuse o
komunikaciu vysle ARP request a dostane odpoved od 'original' PC-b. Preto je
potrebne tieto 'falosne' ARP pakety posielat v istych casovych intervaloch.
Z pozorovani som usudil, ze staci interval 1 minuta.

stav pred utokom:

 ------                   data                   ------

| PC-a |  ------------------------------------- | PC-b |

 ------                                          ------

arp tabulka:                                    arp tabulka:

PC-b: bb-bb-bb-bb-bb-bb                         PC-a: aa-aa-aa-aa-aa-aa

PC-c: cc-cc-cc-cc-cc-cc                         PC-c: cc-cc-cc-cc-cc-cc

stav po (pocas) utoku:

 ------                   data                   ------

| PC-a |  ---------------+     +--------------- | PC-b |

 ------                  |     |                 ------

arp tabulka:             |     |                arp tabulka:

PC-b: cc-cc-cc-cc-cc-cc  |     |                PC-a: cc-cc-cc-cc-cc-cc

PC-c: cc-cc-cc-cc-cc-cc  |     |                PC-c: cc-cc-cc-cc-cc-cc

                         |     |

                         |     |

                         -------    arp tabulka:

                        | PC-C  |   PC-a: aa-aa-aa-aa-aa-aa

                         -------    PC-b: bb-bb-bb-bb-bb-bb

Tato technika funguje na vsetkych beznych switchoch, nakolko switch si mysli,
ze paket posiela tam kde ma (rozhoduje MAC adresa).

Prax:

Tieto techniky su zname uz dlhsiu dobu a primerane tomu existuje vela
programov, ktore umoznuju taketo odchytavania. Pre linux stoji za zmienku
`dsniff`, ktory obsahuje arpspoof pracujuci opisovanym sposobom. Program,
ktory by nieco podobne robil na systeme windows som nenasiel, ale pre
priemerne skuseneho programatora nie je problem takyto program napisat. Mne
osobne trvalo napisanie toho programu zhruba 7 vecerov... Zaujemcom
programatorom odporucam pozriet si kniznicu winpcap, ktora zabezpecuje sietovu
komunikaciu. Staci uz len posielat ARP-y a vhodne preposielat...

Obrana:

Ciastocnym riesenim su VLAN-y, ktore su vsak nastavitelne iba na tych
'drahsich' konfigurovatelnych switchoch.

Inym sposobom obrany je nastavenie statickej ARP tabulky na vsetkych
pocitacoch. Vtedy bude system ignorovat vsetky ARP pakety a bude pouzivat data
zo svojej tabulky. Na linuxe to fungovalo bez problemov, vo windowsoch i
napriek statickym zaznamom po prichode falosneho ARP paketu zmodifikoval
tabulku... (linux rulez :]) Staticke tabulky su samozrejme nepouzitelne pri
vecsich sietach, kde je pri lubovolnej vymene sietovej karty potrebne rucne
modifikovat vsetky tabulky na vsetkych pocitacoch...

Zaver:

Sniffovanie na switchovanej sieti je mozne. Prepinana siet je dokonca z
hladiska bezpecnosti relativne menej bezpecna, ako hub. Relativne preto, lebo
umoznuje nebezpecnejsie utoky, ktore vsak vyzaduju hlbsiu znalost tejto
problematiky a preto nie su tak rozsirene...

Mathew, mathew (zavinac) hysteria (bodka) sk