ugrás a tartalomhoz

How to steal a facebook identity

ochronus · 2011. Nov. 24. (Cs), 01.02
Hogyan "lopjunk el" egy facebook accountot - kicsit esettanulmány, kicsit howto. A cím lehetne: Miért HTTPS HTTP helyett?
 ■
1

Veszélyes a dolog, mert ezzel

Hidvégi Gábor · 2011. Nov. 24. (Cs), 08.28
Veszélyes a dolog, mert ezzel a trükkel gyakorlatilag bármi mást is el lehet lopni, ha jól tudom, ezt hívják packet spoofingnak. Mondjuk a hamisított csomagokat eleve ki kéne szűrnie a routernek vagy a megtámadott számítógépnek.
2

ARP Poisoning, nem packet spoofing

szeber · 2011. Nov. 24. (Cs), 10.01
Ezt ARP poisoning-nak hivjak, nem packet spoofingnak, es a router bele se kerul a kepbe, mivel egy reteggel alacsonyabban mukodik az ARP.
A tamadasnak pont az a lenyege, hogy a cel szamitogep, vagy az egesz LAN ARP tablajaba behirdeti a sajat mac cimet a router IP-jevel, majd a router-nek kuldott csomagokat (vizsgalat utan) tovabbkuldi a routernek. Se a router se a cel szamitogep nem tud ellene vedekezni. Max annyit tehet a rendszergazda, hogy static cimekkent veszi fel minden gepnel az ilyen erzekeny IP cimekhez (router, DNS szerver, stb) tartozo MAC cimeket, csak ha megdoglik a halokartya a gepben, akkor csere utan amig be nem frissiti a klienseken a MAC cimet, addig senki nem fog tudni kommunikalni ezekkel a gepekkel.
Es amugy mint minden man in the middle tamadasnal, igen, gyak barmit el lehet lopni, ami nem titkositva, es a szervert nem autentikalva kommunikal (gyak. nem SSL/TLS-en keresztul).
7

Köszönöm a javítást

Hidvégi Gábor · 2011. Nov. 24. (Cs), 12.28
Döbbenet, nem értem, hogyan létezhet ekkora biztonsági rés...
8

Ugy, hogy a protokoll-t

szeber · 2011. Nov. 24. (Cs), 12.49
Ugy, hogy a protokoll-t 1982-ben terveztek, es mint az osszes IPv4-hez kapcsolodo protokoll, nem ugy lett tervezve, hogy biztonsagos legyen, ez nem volt akkor meg igazan szempont.
9

Nem ez az egyetlen

ochronus · 2011. Nov. 24. (Cs), 13.18
Ó, rengeteg lyuk van/volt az ilyen régi protokollokban, amivel az idők folyamán sokszor visszaéltek. Pár kulcsszó:
TCP szekvenciaszám, TCP SYN flooding, RIP spoofing/poisoning, DNS spoofing/poisoning, Cross-site scripting támadások, ICMP flooding...
3

Igen, veszélyes dolog és

ochronus · 2011. Nov. 24. (Cs), 11.09
Igen, veszélyes dolog és nagyon sok vállalati/egyéb LAN-on nincs ellene védelem. Nem a technológia hiányzik, hanem a hozzáállás. Egyébként igen, számos protokoll "törhető" vele, POP3, IMAP, HTTP-n bármilyen egyszerűbb auth rendszer. Épp ezért írtam meg a cikket, egy ezeréves technika (ARP spoofing/poisoning) még ma is működhet.
5

Azert nem egyszeru vedekezni

szeber · 2011. Nov. 24. (Cs), 11.35
Azert nem egyszeru vedekezni ellene, mivel egy 0 autentikaciot tartalmazo, broadcast alapu protokollrol van szo, a kliensek meg kerdes nelkul beirjak az ARP cache-be, ha kapnak egy ilyen broadcast-ot, es nincs az IP-hez static cim. A static cim kezelese pedig eleg problemas dolog. Az egyetlen gyakorlatban is hasznalhato vedelem ellene az SSL/TLS, vagy ipsec, de olyan helyet meg nem nagyon lattam, ahol belso halon ilyen megoldasokat hasznalnanak.
6

Na igen

ochronus · 2011. Nov. 24. (Cs), 11.56
Igen, nem triviális védekezni ellene, viszont keveset változó belső hálón nem nehéz a static címek kezelése szerintem, csináltam már és segít. Relatíve kevésszer változik meg normál körülmények között egy hálózati eszköz MAC címe :) SSL-en man-in-the-middle-kedni sem lehetetlen egyébként, sajnos.
4

Github repo a kóddal

ochronus · 2011. Nov. 24. (Cs), 11.30
Egyébként ha valakit érdekel, kitettem a kódot:

https://github.com/ochronus/ArpSpoof