Názory k článku Odposloucháváme data na přepínaném Ethernetu (6.)
-
imf (neregistrovaný)Pokud mám správné informace tak IE do verze 6 je defaultne nastaveno, že tomu věřím a tak kliknu, že jsem si vědom, že je to šifrovane spojeni s certifikátem od Verisignu na certifikát , ale kdo ověřuje takovou věc jako fingerprint? A v tu chvíli si s tím uživatelem dělam co chci.
Další možnnost je udělat nějaký DNS spoofing a na svém vebu rozjet aplikaci (nebo její úvodní okno) nějaké banky, kde uvodni prihlaseni je na hrrp clovek vloží svuj login a na mobil mu přijde SMS s nejakym autentizacnim kodem. Ale nijak v te SMS neoverim s kým komunikuji.
Dalsi možnosti je podstrcit uživateli certifikat jako od Verisignu se stejnými napisy a bude se lišit pouze fingerprint a uživatel klikne Yes :)
Takovýchto možností je celá řada
Jen za všechny jeden konkrítní příklad. Známej je danový poradce a na webu MFCR. Tento člověk podava danove priznání desitkam firem. MFCR má certifikát, ale když jsem se snažil sehnat fingerprint jejich certifikátu, tak mi bylo řečeno jejich hotline, at se nestarám a věřím jejich certifikátu.
To jen pár příkladů.
Jinak článek hodnotím jako velmi přínosný
Pavel -
abyssal (neregistrovaný)Mozem potvrdit. Komercne firmy su na tom z mojich skusenosti lepsie, bud na poziadanie aspon poslu fingerprint certifikatu, alebo maju napisane, kde sa da ziskat korenovy certifikat CA.
Nerobim si ale iluzie, ze napr. viac nez 5% klientov CSOB by si bolo schopnych ziskat korenovy certifikat I.CA, nainstalovat si ho do browsera a overit nim certifikat internetbankingu (to plati aj u inych bank, ale nemyslim ze je to chyba bank, aspon nie z vacsej casti). -
Rebel (neregistrovaný)Mam laicky dotaz. Staci k desifrovani odposlechnute SSL komunikace pouze privatni klic serveru? Nebo i kdyz utocnik vlastni privatni klic serveru tak neni schopen komunikaci desifrovat?
A druhy dotaz, disponuje certifikacni autorita i privatnimi klici serveru? Takze teoreticky muze certifikacni autorita desifrovat komunikaci? -
abyssal (neregistrovaný)Ked si nahrate celu sifrovanu komunikaciu, privatnym klucom servera dokazete rozsifrovat premaster secret, zistit master secret, teda aj session key a session klucom rozsifruje celu komunikaciu.
Certifikacna autorita (CA) nikdy nevidela privatny kluc (teda by nemala), nedokaze rozsifrovat komunikaciu so serverom. CA akurat zarucuje, ze overila, ze dany verejny kluc patri serveru s danym domenovym menom (plus sa do toho este mota certifikacna politika, ako a co overila). Uz sa raz stalo, ze si nejaky vtipalek tusim u VeriSignu dal vystavit certifikat Microsoftu, asi to bol najskor nejaky interny zamestnanec. -
abyssal (neregistrovaný)Pozrel som si SSL dokladnejsie a umoznuje dohodu na kluci aj Diffie-Hellmanom (sa mi zdalo divne, ze ten protokol jak je popisany v clanku to nespomina).
Diffie-Hellman dohoda na kluci zarucuje "perfect forward secrecy" (http://en.wikipedia.org/wiki/Perfect_forward_secrecy), rozsifrovanie privatnym klucom servera neprezradi session key, jedine ze by ste vedeli riesit diskretne logaritmy (a to je "hard problem"). Ina situacia by bola keby utocnik mal rootovske prava na serveri, vedel by zistit exponent (nepotreboval by pocitat diskretny logaritmus). -
Dovolil bych si s clankem souhlasit pouze castecne. Je rozhodne dobre vedet, ze tento typ utoku existuje,jak ho nasimulovat a jak se projevuje. Nicmene nedoporucuji utok provadet.
V clanku ale chybi to podstatne:
Co v pripade, ze mam podezdreni na utok typu man-in-the-middle delat ?
Pripravovali demonstraci podobneho utok na uzivatele fiktivniho internetoveho bankovnictvi na IT&Security Conference 2005. Pokud Vam to bude prinosne, zde jsou pristupne materialy:
http://www.logios.cz/a/logios-bezpecnost-internetoveho-bankovnictvi/61
Cili doplnim.
V okamziku, kdy mate podezdreni na utok Man-In-The-Middle vemte do ruky tistene materialy popripade smlouvy, kde budou zverejneny kontaktni telefony na podporu (v zadnem pripade neduverujte cemukoliv, co je na internetu) a trvejte na tom, aby s Vami overili pravost certifikat serveru. Nejlepe na zaklade fingerprintu(otisku).
Proc neduverovat v danem okamziku internetu ? Kdyz uz bude utocnik mezi Vami a serverem na sifrovane ceste, pak bude i na nesifrovane a muze si se spojenim delat co chce. Nejen cist, ale i menit veskerou komunikaci dle sve potreby.
Toto uz Cain&Abel neumoznuje, ale pro potencionalniho utocnika to je vice nez snadne. -
Ve standardni instalaci Windows jiz mate spoustu certifikatu znamych CA. To znamena ze se k vam dostali cestou, ktera by mela byt v poradku. Pokud vam toto uloziste nikdo nemodifikuje nemelo by se stat ze by mel nekdo certifikat podepsan CA, kterou v ulozisti nemate. Samozrejme ze tam nejsou veskere CA, ale nektere CA tam nejsou napriklad z nedostatecne bezpecnostni politiky pri pridelovani certifikatu. Proto bych certifikatum podepsanym CA, ktere neduverujete neveril. -
ltx (neregistrovaný)Nesouvisí to s článkem, ale zeptám se, zda to někdo neví: nevíte někdo, jak kontrolovat, že si uživatel nezměnil na síťové kartě MAC adresu? Vím, že to (aspoň částečně) jde, viděl jsem to fungovat, tipuju, že to funguje tak, že se v rámci ethernetové auto-negotiation zjistí výrobce karty a porovná, zda k němu sedí první tři byty MAC adresy (kód výrobce). Když se vypne autonegotiation, tak se to dá obejít a člověk se napojí s libovolnou kartou. Nemá někdo konkrétní popis dané technologie?
-
ltx (neregistrovaný)Tady jde o ten případ, kdy:
* vezmu síťovou kartu s její přirozenou MAC --- síť funguje.
* vezmu jinou síťovou kartu a nastavím na ní MAC předchozí karty --- síť nefunguje (přitom chyba není v nastavení této karty, v jiné síti funguje).
* vezmu tutéž síťovou kartu, nastavím na ní MAC předchozí karty, vypnu autonegotiation --- síť funguje.
Nikdy předtím jsem nic takového neviděl ani o tom neslyšel. -
anonymníTohle všechno je hezké a mně i dávno známé. Útoku se říká MID, man-in-the-middle. Problém je jen v jednom: v těch certifikátech: zapnete online banking, nahodí se Java virtual machine a začne Vám hlásit, jestli chcete pokračovat, že podpis je OK atd., jen ta certifikační autorita je prostě nějaký "noname". Banka si prostě udělá svojí certifikační autoritu a není ochotná zaplatit těch pár desítek dolarů (ne-li stovek) za rozumný certifikát. Řeknete si, že to přeci není problém, stačí to naimportovat jen jednou - jenže tohle nedělá jen jedna banka (přehled ale o všech nemám) a za druhé - kdo má tohle kontrolovat (buď fingerprint či nějak podobně rozumným způsobem)... Takže 99% uživatelů je pak stejně nuceno odklepnout u své internetové banky, že je všechno OK - a to jedno procento, které si ověřilo fingerprint jsou holt paranoidní adminové... Dnes bych z toho důvodu ani omylem nešel do bankovnictví, které je čistě elektronické, tedy vše jede přes moje a bankovní privátní klíče. Jakmile je k tomu alespoň malá krabička (ani nemusí fungovat na principu veřejné kryptografie, jak to má u své krabičky Ebanka, stačí buď ten levný RSA generátor či cokoli podobného, co má např. HVB) - případně stejnou funkci splní i sekundární ověřování pomocí SMSky zaslané na předdefinovaný telefon. A klidně nezabezpečené (čili normální SMSka, ne v rámci SIM toolkitového bankingu). Pak jsou na mne celkem krátcí i všichni MID útočníci a všichni, co mi napíchli klávesnici, aby si přečetli heslo k mému privátnímu klíči (a dnešní viry jsou hlavně o tomhle a ne o zobrazování hlášky "dej mi sušenku")... Howgh...
-
Petr (neregistrovaný)SMS pomuze jen v pripade, ze je tam kompletne vypsana transakce. (Tj. zapomente na soukromi :-)) A ze si skutecne zkontrolujete, ze ten autorizacni kod nalezi k transakci, kterou chcete provadet.
Jinak man-in-the-middle porad muze fungovat: Vy mu pretukate ze sve SMS autorizacni klic do jeho okna, on ho preposle bance - a prave jste mu dal svoleni prevest vsechny sve penize na ucet bileho kone. -
mm (neregistrovaný)No, kontrola, zda SMS klic nalezi k transakci, kterou mam na monitoru je samozrejme velice dulezita.
Ale neni mne moc jasna ta myslenka s man-in-the-middle v souvislosti se SMS autorizaci.
Dejme tomu, ze jsem tak blbej, ze mne podstrci vlastni verze webu banky (viz. overovani certifikatu). Cela akce by pak ale byla pomerne slozita - musel by bance nejak emulovat uplne jinou transakci na mem uctu, zatimco ja bych na monitoru videl, ze delam neco uplne jineho...
Samozrejme by se melo dodat, ze sila celeho systemu SMS klicu je v tom, ze jsou pouzity ve spojeni s heslem a certifikatem. SMS klic podle me slouzi hlavne k tomu, aby s vasim uctem nemohl nikdo manipulovat jen na zaklade nejak zjisteneho jmena a hesla...A kontrola certifikatu banky JE ZAKLAD. -
Petr (neregistrovaný)Jadro meho argumentu je v tom, ze ve vetsine pripadu SMS autorizace man-in-the-middle neznemoznuje.
Obecne konstatovani je, ze uzivatele vetsinou certifikat nekontroluji. (To, ze ceske banky nemivaji certifikat podepsany nejakou defaultne instalovanou CA, tomu jeste napomaha.) Chyba "certifikat byl vystaven pro nekoho jineho" je natolik casta, ze hlasku o divnem certifikatu vsichnio odklikavaji automaticky.
Tento automatismus uzivatelu umoznuje man-in-the-middle proti https.
A pointa je v tom, ze SMS tomuto man-in-the-middle nezabrani.
Scenar:
1. Prihlasim se k podvrzenemu webu banky.
2. Server utocnika se prihlasi ke skutecnemu webu banky.
3. Prihlasim se (user id, PIN atd.). Utocnik to preda bance beze zmeny.
4. Zadam nejakou zajimavou transakci na webu utocnika (napr. v pripade CSOB bankingu hromadny prikaz k uhrade). Utocnik na webu banky zada hromadny prikaz na stejnou castku, ale na jina cisla uctu.
5. Prijde mi SMS, ktera obsahuje autorizacni kod. SMS rika, ze chci prevest X korun, jenze nerika kam.
6. Ja SMS nadatlim na web utocnika, ten ji preposle bance - a voila!
SMS klic nezabrani manipulaci s mym uctem jen na zaklade jmena a hesla, pokud ten utok probiha v dobe, kdy si ja myslim, ze jsem ja pripojeny. -
Buki (neregistrovaný)teda nejsem odbornik, ale rekl bych, ze ten overovaci kod, ktery obdrzite v SMS, je nejaky hash, jehoz soli jsou i udaje o danem prevodu, takze utocnik nebude schopen prevest jinou castku na jiny ucet. Ale samozrejme si to muzu predstavovat prilis idealisticky a pravda je jinde ...
-
Petr (neregistrovaný)Prominte, ale ktera respektovana autorita delala audit zabezpeceni eBanky a kde je jeho vystup (vcetne metodiky, uvazovanych utoku, vyhodnoceni internich procesu (aby se nezanesla do auditovaneho systemu chyba pri nejake zmene) atd.)?
Pripada mi to, ze u eBanky sice vsichni veri, ze to je bezpecne (vypada to bezpecne a v novinach se o zadnem problemu nepsalo), ale je to vira nezalozena na faktech. -
anonymníjj C&A pri spusteni, nebo instalaci vydrazdi muj symantec k nepricetnosti a je okamzite smazan.....no ale poradim si :) takovy AVG si toho ani nevsimne :P
Myslim, ze zadny ´skodlivy´kod tam asi neni, jen proste ten program pouziva velni nestandartni a pro AV soft pochopitelne podezdrele techniky -
Citace z domovskych stranek:
Q: Is this program a virus ?
A: No, absolutely not ! The program does not infect files, it does not send your password over the Internet, it does not propagate itself and it does not contain spyware code. If you don't trust the me you can check it yourself using your preferred personal firewall software. As proof of contents, in every release of the program the executable and .DLL files are always signed by the author. You can find mao's PGP public-key here. -
A jeste jedna presnejsi:
oxid.it is not a virii site
Antivirus vendors could have signatures for some of the programs on this site. Cain & Abel v2.0 for example has been classified as a low-risk troyan virus even if the program's features are all documented in the manual.rtf file and Abel (the server component) is completely visible (the blue icon in the system tray). I can assure to you that there are no viruses or hidden features in the programs from my site. Cain & Abel v2.0 does not infect files, it does not send your passwords over the Internet or anything like that....
ČLÁNKY DO MAILU