Tanulmány a youtube.com leállásról

Internet, Közösségi média

A RIPE NCC egy esettanulmányt készített a youtube.com ominózus február 24-i "eltérítéséről". Igen-igen részletes, alapos, érdemes elolvasni. Elérhető itt.

( Elbandi v | 2008. 02. 29., p – 22:39 )

jol ertem, hogy veletlenul "szetspameltek" a netet, hogy a youtube pakisztanban talalhato. ezert nem volt elerheto senkinek sem. aztan a youtube rajott hogy valami gaz van, ezert kisebb tartomanyt kezdett el hirdetni (mert annak nagyobb a prioritasa).

Ezzel ugye az a gond, hogyha gonosz hakker betor egy szolgaltatohoz, elkeszdi szorni, hogy a ebay/ms/akarmi ott talalhato, akkor egyfajta DoS tamadast tud csinalni...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

igen, a pakisztani szolgaltato azt mondta, hogy neki van a legrovidebb eleresiutja a youtube fele, ezt a PCCW elhitte (ok szolgaltatjak a fel kozel/tavolkeletnek a netet).
es ezert minden a pccw ala tartozo vegpont pakisztan fele akart kimenni a youtube-re, ok meg a teljes forgalmat betoltak a kukaba.

igazsag szerint itt nem is az a gaz, hogy youtube nem volt elerheto, vagy mondjuk a youtube latogatokat ra tudod "uszitani" egy masik szerverre.
szerintem inkabb az, hogy ha jol ertem, akkor siman megtehettek volna a pakisztaniak, hogy csinalnak egy kamu youtube site-ot, es akik az o altaluk ajanlott routing utvonalat kovetik, azok teljesen megteveszthetoek.

tehat pl. ha en lennek egy isp, es azt mondanam, hogy en tudom a legrovidebb utat az otp bankhoz, ezek utan beroutingolom egy sajat szerveremre az osszes otp-s forgalmat, akkor nagy valoszinuseggel atvennek tolem a magyar csomopontok az infot, es hozzam jonne minden eredetileg az otp-nek szant keres, en meg jol begyujthetnem a szamlaszamokat, jelszavakat, stb.

Tyrael

A Youtube esetén nincs szó DNS poisoning-ról, a DNS bejegyzések változatlanok maradtak, csak más útvonalakat hirdettek ki, ezért másfele irányították a forgalmat a routerek...

A kamu otp weboldalnál két probléma van (mindkét támadásfajtánál):

1. Rendelkezned kell egy _hiteles_ otpbank.hu ssl tanusítvánnyal, hogy ha https-en keresztül akarsz adathalászni, különben a felugró "Certificate Error" ablak miatt az ügyfelek elég gyorsan elkezdenek érdeklődni a banknál, hogy wtf és megindul a nyomozás.

2. Sima http adathalászat esetén egyrészről attól kell félned, hogy melyik ügyfélnek tűnik fel először, hogy nem biztonságos kapcsolaton keresztül megy a webes netbank, másrészről, hogy ez esetben rajtad kívül még más is hozzájuthat az adatokhoz (pl. aki sniffeli a forgalmat ;).

csak vaktaban lovoldozok, de:
http://en.wikipedia.org/wiki/Secure_Sockets_Layer#TLS_handshake_in_deta…
http://en.wikipedia.org/wiki/Man-in-the-middle_attack

A man-in-the-middle attack can only be successful when the attacker can impersonate each endpoint to the satisfaction of the other. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, SSL authenticates the server using a mutually trusted certification authority.

Szoval ha csak man-in-the-middle-t csinalsz egy ssl-es oldalra, akkor a kliens rajon a turpissagra, mert a kapott certification-ben levo cim nem egyezik meg az altala meglatogatott cimhez.
de ha el tudom hijackelni azt a cimet, amihez a cert-et kiallitottak, akkor mukodhet a man-in-the-middle, es mikor a kliens megnezi, hogy kinek a nevere szol a tanusitvany, akkor latni fogja, hogy minden rendben, mert az enyemre.
valaki szakertobb majd megcafolhat.

meg1 idezet a wikirol:

To protect against Man-in-the-middle attacks, the client compares the actual DNS name of the server to the DNS name on the certificate. Browser-dependent, not defined by TLS.

Sot, mivel ugye rajtunk routeolodik at a handshake, mar eleve jatszhatunk azzal, hogy hiaba mondja azt a kliens, hogy tamogatja a legerosebb ssl/tls protokolokat, mivel a handshake meg nem titkositott csatornan meg, siman megtehetjuk, hogy az eredeti szerver fele mar azt hazudjuk, hogy csak a sebezhetobb, regi ssl verziot ismerjuk.

na, szoval miutan ujra vegineztem/gondoltam:
ha el tudjuk lopni a domaint, akkor hasznalhatjuk az eredeti certet, a kliens el fogja hinni, hogy a mienk, mert csak domain nevet tud ellenorizni, azt meg ugye elbitoroltuk.
ezutan man-in-the-middle-lel lehalgatjuk az egesz handshaket, ami alapjan hozzajutunk a privat, es a publikus kulcsaihoz mindket felnek, ezutan mar tudjuk irni/olvasni a titkositott csatornat.

Tyrael

Huh, ez nem ilyen egyszerű... :)

A böngésző (kliens) három dolgot ellenőriz egy https oldal meglátogatásakor:

1. A tanúsítvány - amelyet a szerver elküld a kliensnek az ssl/tls handshake alkalmával - egy olyan szervezet által van-e kiadva, amelyikben megbízik a user. (Alapesetben a böngészők csak a nagyobb tanúsítványkiadó központok által kiadottakat fogadják el megbízhatónak.)

2. A tanúsítvány dátuma rendben van. (A kliens számítógép órája alapján a dátum beleesik a tanúsítványban szereplő időintervallumba: érvényes-e már, illetve nem járt-e még le.)

3. A tanúsítványban szereplő cím, megegyezik a kliens által meglátogatott weboldal címével.

Az utolsó kettőt viszonylag könnyű megoldani (hisz akár csak generálsz saját magad egy kulcsot, amelyet utána saját magad aláírsz), az első feltételt viszont csak úgy tudod megoldani, ha ellopod a szerver privát kulcsát, amelyhez tartozik a tanúsítvány vagy ha hozzáférsz egy tanúsítványkiadó központ (CA) rendszeréhez és aláírod a saját magad által generált kulcsodat.

az eredeti szervernek van hiteles tanusitvanya, miert nem tudom azt "tovabbadni" a kliensnek?
mikor handshake-elek az eredeti szerverrel, akkor ugyis elkuldi nekem a certet, en meg szepen tovabbpasszolom a kliensnek, es o ellenorizhet rajta mindent, amit akar, stimmelni fognak az adatok, nem?
mintha elbeszelnenk egymas mellett.
asszem az a legegyszerubb, ha kiprobalom.

Tyrael

A tanúsítvány kvázi a szerver publikus kulcsának egy hitelesített aláírása a tanúsítványkiadó privát kulcsával. Te hiába rendelkezel a szerver tanúsítványával, ha a privát kulcsa nincs a kezedben. Ha a handshake alatt kicseréled a szerver publikus kulcsát a sajátodra, akkor lebuksz, mert a tanúsítvány nem ahoz készült. Ha nem cseréled ki, akkor meg szépen megtörténik a handshake a kliens és a szerver között és te utána nem látod a plaintext http forgalmat, csak a titkosítottat... ;)

a handshake soran legalabb a nyilvanos kulcsokat el tudom fogni.
azzal pedig tudok xy neveben irogatni, meg ha az adatokat nem is tudom elolvasni, nem?
bar a tranzakciokhoz meg a bankok altalaban mindig kernek jelszot, azt meg ha nem tudom elolvasni, akkor hiaba tudnek a user neveben atutalast kezdemenyezni. :(
viszont az meg mindig szobajohet, hogy handshake soran, mikor a kliens az altala tamogatott titkositasi eljarasokat es modszereket kozli a szerverrel, akkor azt meghamisitom, es ha az eredeti szerver engedi, akkor gyengebb verziot kenyszerithetek.

# SSL v2 has a weak MAC construction and relies solely on the MD5 hash function.
# SSL v2 does not have any protection for the handshake, meaning a Man-in-the-middle downgrade attack can go undetected.

:)

SSL v2 is disabled by default in Internet Explorer 7,[1] Mozilla Firefox 2,[2] Opera 9[3] and Safari. Support for SSL v2 (and weak 40-bit and 56-bit ciphers) will be removed completely from the upcoming Opera 9.5 (code-named Kestrel).[4]

:(

Tyrael

a handshake soran legalabb a nyilvanos kulcsokat el tudom fogni. azzal pedig tudok xy neveben irogatni, meg ha az adatokat nem is tudom elolvasni, nem?

Nem, mert a titkosítás nem a publikus kulccsal történik, hanem a handshake során megbeszélt egyedi kulccsal, amit a nyilvános kulcsú titkosítással rejtjelezve beszél meg a két fél. :)

viszont az meg mindig szobajohet, hogy handshake soran, mikor a kliens az altala tamogatott titkositasi eljarasokat es modszereket kozli a szerverrel, akkor azt meghamisitom, es ha az eredeti szerver engedi, akkor gyengebb verziot kenyszerithetek.

Igen, ez egy létező támadás volt az SSLv2-nél, de egyrészről (ahogy írtad is) a mostani böngészők azt már nem engedélyezik alapból, másrészről ha régebbi klienst is használ az ügyfél, a szerver oldalon (remélhetőleg) szintén tiltva van a "rollback".

Ez a cikk gagyi.

A broadcast kifejezésnek köze nincs a routinghoz, itt az advertising-ot kellett volna használni. A lényeg, hogy a "paktel" behírdetett egy /24-et a youtube /22-jéből, amit a pccw elfogadott és továbbhírdetett. Ezt nem kellett volna neki, mivel minden valamire való szolgáltató a downstream vonalain (IP registry DB-ben tároltak alapján, pl. nálunk RIPE) szűri a hozzá érkező hírdetéseket. Mivel a pccw már elég nagy, ezért a többi "nagy" már bízott benne, így klasszul "körbement" a (more specific) prefix, ami a Pakisztánba mutatott.

Persze alapvetően már a /24-es prefixek elfogadásával és kiadásával is gázok vannak, de a "micro-szolgáltatók" netre engedésével sikerült megoldani a global bgp-tábla frankó exponenciális növekedését..

( bandix | 2008. 03. 01., szo – 09:24 )

Internetterrorizmus?
____________________________________________________________
Slackware 12/current - linux-2.6.24.2-olorin - KDE 3.5.8

( hg2ebh | 2008. 03. 02., v – 01:41 )

Kicsit off, mert nem az eredeti témához tartozik, de:
Szerinted egy eccségsugarú OTP-s webbankos júzer foglalkozik azzal, hogy http vagy https van a fejlécben? :)

Erre nem tudok biztosat mondani, mert ilyen tapasztalatom nincs, de az biztos, hogy https esetén, ha gond van a tanúsítvánnyal, akkor az ügyfelek jórésze betelefonál, függetlenül attól, hogy tudja vagy érti a mögötte húzódó problémát vagy sem. Persze nyilván feltűnő, hisz a böngészők nagy lármát csapnak ilyen esetben (IE7 esetén a piros "tovább (nem javasolt)" feliratra jórészük rá se mer alapból kattintani - szerencsére - :), http esetén meg maximum az tűnhet fel az átlag usernek, hogy "nincs kis lakat" vagy "nem színes a címsor", tehát biztos, hogy kisebb arányban veszik észre és telefonálnak be, de azért - szerintem - lenne olyan viszonylag kis időn belül akinek feltűnik.

Érdekesebb probléma viszont a kifejezetten banki csalásokra kihegyezett malware/trójai programok, amelyeken keresztül a támadók az ügyfél által már felépített https session-be, a hitelesítés után (a jelszó és egyéb egyszeri kód begépelése után) injektálják a saját megbízásaikat, átutalásaikat... ;)

namost peldaul: user beirja: www.otp.hu. normalis esetben ez egy 302-vel atugrik http://www.otp.hu/index.html-re, amiben csak egy meta-refresh van, ami atiranyitja https://www.otpbank.hu/...-re.

tehat a 302es az index.html meg sima http. tegyuk fel, hogy IE-hez van egy exploit, amihez eleg csak megnezni egy oldalt, es mar fertozottek vagyunk. Gonosz ISP szetterjeszti, hogy 195.228.112.250 ip nala van. aztan az index.html-ben nemcsak a metarefresh jon, hanem az expolit is. aztan a https forgalmat mar csak valahogy proxyzza a rendes helyre. nemerdekes mi van a https-ben, az user gepen mar ott a progi.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!