Keresés

Új hozzászólás Aktív témák

  • PJohn

    csendes tag

    válasz szab.tam #1 üzenetére

    Elsősorban az adatokba való belenyúlás a lényeg, de ehhez az adatot előbb el kell téríteni. (Előrebocsájtom, hogy se biztonságtechnikai szakértő nem vagyok, szóval sok bizonyára sok pontatlanság van az alábbiakban, de a lényeg szerintem átmegy.)

    A klasszikus példa a man-in-the-middle támadás, amikor a felhasználó azt hiszi, hogy az általa keresett szerverhez csatlakozott, de valójában a támadó szerveréhez, viszont az a szerver nagyjából semmi mást nem csinál, csak mindent továbbít a felhasználótól a valódi szerverig, és vissza, csakhogy eközben lehallgatja az adatokat, és jelszavakat, és egyéb érzékeny adatokat szerezhet meg. Ha akar, akkor megváltoztathat ezt-azt (gyakorlatilag mindent).

    Majdnem olyan, mintha lehallgatnák a nyílt wifit, de azzal csak lehallgatni tudsz, belenyúlni nem. Viszont ezzel a támadással módosítani is lehet bizonyos adatokat. A nyílt wifi esetével ellentétben a man-in-the-middle problémája, hogy a titkosítás nem véd ellene, mivel ha egyszerű titkosítást használsz, nem sok minden akadályozza meg abban a középső, hamis szervert, hogy dekódolja az adatokat, amiket küldesz neki (hiszen azzal a kulccsal titkosítottad, amit a hamis szervertől kaptál), elolvassa azokat, majd újra titkosítsa, ezúttal az eredeti szerver kulcsával, és úgy küldje tovább az eredeti szervernek, mintha az tőled érkezne.

    Ezért van az, hogy a helyesen implementált HTTPS/SSL-ben nem csak a titkosítás a fontos, hanem a szerver tanúsítványának az azonosítása is. Már így is elég részletes a dolog, szóval röviden: az eredeti szerver tanusítványát kulcsát aláírják egy megbízható kulccsal, amiket az oprendszerek ismernek, és ezt már egy közbeékelt hamis szerver nem tudja utánozni, mert az ő tanúsítványa/kulcsa nem lesz aláírva, legfeljebb saját magának írja alá, vagy valami másik kamu tanusítvány kulcsával, ekkor jelenik meg a böngésződben a "valószínűleg ez nem az a webhely, amit keres" figyelmeztetés. A forgalom ekkor is titkosítva van, tehát ha mégis stimmel az oldal (tehát egy legitim szervernek van megbízhatatlan tanúsítványa), akkor külső fél elméletben lehallgatni nem tudja, mert titkos, de ha egy hamis oldalnak küldöd eleve, akkor ugye a titkosítás nem segít.

    A man-in-the-browser támadás elvben hasonlóan működik, tehát az adat nem közvetlenül a képernyődre érkezik, hanem előbb a bűnözők látják, és azt csinálnak vele, amit akarnak. A különbség az, hogy míg a man-in-the-middle támadásnál a bűnözők az igazi szerver és a te géped közé vannak harmadik félként beépülve, addig a man-in-the-browser támadásnál a jó szerver előbb a te gépedre küldi az adatot, de mielőtt azt feldolgozná a böngésző, továbbküldi a te gépedről a bűnözőknek, és visszaküldik a módosított oldalt a gépedre. (Ehhez persze fertőzött gép kell, mert normális gép ilyet nem csinál, míg a man-in-the-middle támadáshoz nem kell fertőzés). Ez esetben ha jól értem, akkor a kedvezményezett "számlaszámát" módosítják, úgy, hogy nekik menjen a pénz, mikor kifizeted a böngészőben.

    Analógiával: képzeld el, hogy igényelsz valami cégtől egy csekket, hogy befizess valamit. Az el is jut a postaládáig, de egy gonosz postahacker ott leselkedik a házad előtt, és kikapja a postaládából az eredeti csekket, és elküldi a főhadiszállásukra, ahol kikaparják belőle az eredeti cég számlaszámát, és beleírják a sajátjukat, majd újra elküldik neked, te meg mivel számítottál a csekkre, stimmel minden, elmész, és gyanútlanul befizeted.

    Ezzel szemben a man-in-the-middle analógiája az lenne, ha valaki alapítana egy ELMŰ Számlák Kft. nevű kamu céget, és valahogy megoldaná (megtévesztené az embereket, vagy meghackelné a postarendszert), hogy az ELMŰ-nek írt leveleket inkább nekik küldjék, és a saját címükről továbbküldenék az ELMŰ-nek, mintha ők lennének az ügyfél, és az ELMŰ nekik küldené vissza a csekket, amit aztán az ELMŰ Számlák Kft. bűnözői úgy modosítanának, hogy mikor befizeted, akkor nekik küldje a pénzt, és ne az ELMŰ-nek, majd azt elküldik neked, te meg azt hiszed, hogy az elműtől jött, a tartozásod mértéke is stimmel, hiszen az az ELMŰ eredeti számláján is rajta volt, amit nem változtattak meg, és mivel minden stimmel, csak a számlaszám nem, befizeted.

    Egy valós példa, man-in-the-middle veszélyre: Nem sokkal ezelőttig volt egy facebook.hu nevű domain, aminek semmi köze nem volt a facebookhoz, arra használta aki regisztrálta, hogy egy reklámot jelenítsen meg a böngésződben, majd automatikusan átirányítson a facebook.com-ra. Ezzel idáig semmi baj, de elég sok (magyar) laikust láttam ezt használva belépni a facebookra, amivel az a baj, hogy ezt a szervert elméletben bármikor beállíthatnák úgy, hogy ahelyett, hogy átirányítja a felhasználót, inkább kérje le a facebook főoldalát, és küldje tovább a felhasználónak, mintha ő lenne a facebook, az user meg begépeli a felhasználónevét és jelszavát, elküldi a facebook.hu-nak, aki továbbküldi a facebook.com-nak, és így tovább... Ebből az user semmit nem vesz észre, mert közvetve az igazi facebook-kal kommunikál, de minden adatát látja és rögzítheti a facebook.hu, elsősorban a jelszó érdekes, de biztos mennek egyéb érzékeny adatok is facebookra, például biztos vannak idióták tudatlanok, akik facebook chat-en küldözgetnek hitelkártyaszámokat a párjuknak, vagy ilyesmi.

    Amúgy ha a facebook.hu csak annyit csinálna, hogy lemásolja a facebook főoldalát, de nem továbbit az igazi facebooknak semmit, csak hagyja, hogy a kamuoldalra beírják a felhasználók a belépési adataikat, és eltárolja őket, akkor ugyanezt adathalászatnak hívják. Ezt könnyebb felismerni, mert pl. miután belépsz a kamu oldalon, nem tud semmi hihetőt mutatni, nem úgy néz ki, mintha tényleg beléptél volna, de addigra már késő.

    Bár ha jól látom, már nem működik a facebook.hu hál'istennek, sőt, WHOIS alapján már a facebook-é. Kb egy éve még élt és virult, és senkinek nem tűnt fel, hogy az nem a facebook. Bár régen meg nem néztem WHOIS-t, de lerítt róla, hogy valami tákolt izé.

Új hozzászólás Aktív témák