Útok makléře

Intermediary attack neboli útok muže uprostřed ( MITM) – typ  útoku v kryptografii a počítačové bezpečnosti , kdy útočník tajně přenáší a v případě potřeby mění spojení mezi dvěma stranami, které se domnívají, že spolu přímo komunikují s přítel. Jedná se o metodu kompromitace komunikačního kanálu , při které útočník po připojení ke kanálu mezi protistranami zasahuje do přenosového protokolu, maže nebo zkresluje informace.

Jedním z příkladů útoku typu man-in-the-middle je aktivní odposlouchávání, při kterém útočník naváže nezávislé spojení s oběťmi a předává si mezi nimi zprávy. Tím nutí oběti uvěřit, že spolu mluví přímo prostřednictvím soukromého spojení, ve skutečnosti je celý rozhovor řízen útočníkem. Útočník musí být schopen zachytit všechny zprávy přenášené mezi dvěma oběťmi a také zavést nové. Ve většině případů je to docela jednoduché: útočník se například může chovat jako „muž uprostřed“ v dosahu bezdrátového přístupového bodu ( Wi-Fi ) [1] .

Tento útok má za cíl obejít vzájemnou autentizaci nebo její nedostatek a může být úspěšný pouze tehdy, když má útočník schopnost vydávat se za každý koncový bod nebo zůstat neodhalen jako mezihostitel. Většina kryptografických protokolů obsahuje určitou formu autentizace koncového bodu , která má zabránit útokům MITM. TLS může například ověřit jednu nebo obě strany pomocí vzájemně důvěryhodné certifikační autority [2] .

Princip útoku

Útok obvykle začíná nasloucháním komunikačnímu kanálu a končí tím, že se kryptoanalytik snaží zachycenou zprávu nahradit, extrahovat z ní užitečné informace a přesměrovat ji na nějaký externí zdroj.

Předpokládejme, že objekt A plánuje odeslat nějaké informace objektu B. Objekt C má znalosti o struktuře a vlastnostech použité metody přenosu dat, stejně jako o tom, že plánovaný přenos skutečných informací, které C plánuje zachytit. K provedení útoku se C „představí“ objektu A jako B a objektu B jako A. Objekt A, který se mylně domnívá, že posílá informace B, je pošle objektu C. Objekt C poté, co informaci obdržel a provádění některých akcí s ním (například kopírování nebo úpravy pro vlastní účely), odesílá data samotnému příjemci - B; objekt B se zase domnívá, že informace obdržel přímo od A.

Příklady útoků

Příklad útoku v algoritmickém jazyce

Předpokládejme , že Alice chce dát Bobovi nějaké informace. Mallory chce zachytit zprávu a případně ji změnit, aby Bob dostal špatné informace.

Malory zahájí svůj útok navázáním spojení s Bobem a Alicí, přičemž oni nemohou odhadnout, že v jejich komunikačním kanálu je přítomen někdo jiný. Všechny zprávy, které Bob a Alice posílají, procházejí přes Mallory.

Alice žádá Boba o jeho veřejný klíč . Malory se Alici představí jako Bob a pošle jí svůj veřejný klíč. Alice, která věří, že je to Bobův klíč, s ním zašifruje zprávu a pošle ji Bobovi. Mallory zprávu přijme, dešifruje, pak v případě potřeby upraví, zašifruje Bobovým veřejným klíčem a odešle mu ji. Bob obdrží zprávu a myslí si, že přišla od Alice:

  1. Alice pošle Bobovi zprávu, kterou Mallory zachytí: Alice „Ahoj Bobe, tady Alice. Pošlete mi svůj veřejný klíč." → Mallory Bob
  2. Malory předá zprávu Bobovi; Bob nemůže odhadnout, že tato zpráva není od Alice: Alice Mallory „Ahoj Bobe, tady Alice. Pošlete mi svůj veřejný klíč." → Bob
  3. Bob posílá svůj klíč: Alice Mallory ← [Bobův klíč] Bob
  4. Malory nahradí Bobův klíč svým a předá zprávu Alici: Alice ← [Klíč Malorie] Mallory Bob
  5. Alice zašifruje zprávu Malloryho klíčem a věří, že je to Bobův klíč a pouze on ji může dešifrovat: Alice "Sejdeme se na zastávce!" [zašifrováno Malloryho klíčem] → Mallory Bob
  6. Malory zprávu dešifruje, přečte, upraví, zašifruje Bobovým klíčem a odešle: Alice Mallory "Sejdeme se u vchodu do muzea v 18:00." [zašifrováno Bobovým klíčem] → Bob
  7. Bob si myslí, že tohle je Aliceino poselství.

Tento příklad demonstruje potřebu použít metody k ověření, že obě strany používají správné veřejné klíče, tj. že strana A má veřejný klíč strany B a strana B má veřejný klíč strany A uprostřed."

Útok na protokol Diffie-Hellman

Zvažte útok na sdílený tajný protokol Diffie - Hellmana mezi stranami A a B. Předpokládejme, že kryptoanalytik E má schopnost nejen zachytit zprávy, ale také je nahradit svými vlastními, to znamená provést aktivní útok:

Zachycování a záměna klíčů

  1. Strana A pošle zprávu straně B :
  2. Cryptanalyst E zachytí zprávu strany A a nahradí ji zasláním jiné zprávy straně B :
  3. Strana B pošle zprávu straně A :
  4. Kryptanalytik E zachytí zprávu strany B a nahradí ji tím, že straně A pošle nějakou vlastní zprávu:
  5. Výsledkem těchto akcí je vytvoření dvou komunikačních kanálů mezi kryptoanalytikem E a stranami A a B a strana A věří, že komunikuje se stranou B pomocí tajného klíče , a strana B posílá zprávy pomocí klíče . Strany A a B přitom nemají podezření, že k výměně zpráv nedochází přímo, ale prostřednictvím kryptoanalytika E :

Spoofing zpráv

  1. Strana A odešle zprávu straně B zašifrovanou klíčem :
  2. Cryptanalyst E zachytí tuto zprávu, dešifruje ji pomocí klíče , v případě potřeby ji změní na , zašifruje ji pomocí klíče a odešle straně B : :
  3. Cryptanalyst E provádí podobné akce při odesílání zpráv z B do A .

Kryptanalytik E tak dostane příležitost zachytit a nahradit všechny zprávy v komunikačním kanálu. Zároveň, pokud obsah zpráv neumožňuje odhalit přítomnost třetí strany v komunikačním kanálu, je útok „muž uprostřed“ považován za úspěšný.

SSL útok typu man-in-the-middle

V tomto příkladu budeme zvažovat útok na SSL přes HTTP , také známý jako HTTPS, protože se jedná o nejběžnější implementační model pro protokol SSL a používá se téměř ve všech bankovních síťových aplikačních systémech, e-mailových službách k poskytování komunikačního kanálu. šifrování. Tato technologie je navržena tak, aby zajistila bezpečnost dat před zachycením třetími stranami pomocí jednoduchého snifferu paketů.

Zvažte proces komunikace přes HTTPS na příkladu připojení uživatele k účtu Google. Tento proces zahrnuje několik samostatných operací:

  1. Klientský prohlížeč přistupuje na http://mail.google.com na portu 80 pomocí HTTP.
  2. Server přesměruje HTTPS verzi tohoto webu klienta pomocí přesměrování HTTP kódu 302.
  3. Klient se připojí k https://mail.google.com na portu 443.
  4. Server předloží svůj certifikát veřejného klíče klientovi za účelem ověření webu.
  5. Klient ověří tento certifikát podle svého seznamu důvěryhodných CA.
  6. Je vytvořeno šifrované spojení.

Ze všech těchto akcí se zdá být nejzranitelnější přesměrování na HTTPS prostřednictvím kódu odpovědi HTTP 302. K útoku na přechodový bod z nezabezpečeného kanálu na zabezpečený byl vytvořen speciální nástroj SSLStrip . Pomocí tohoto nástroje je proces útoku následující:

  1. Zachycování provozu mezi klientem a webovým serverem.
  2. Když je nalezena adresa URL HTTPS, nástroj SSLstrip ji nahradí odkazem HTTP, který odpovídá všem změnám.
  3. Útočící stroj poskytuje certifikáty webovému serveru a vydává se za klienta.
  4. Provoz je přijímán ze zabezpečené webové stránky a je poskytován klientovi.

Výsledkem je, že útočník získá přístup k datům, která klient odesílá na server. Těmito údaji mohou být hesla k účtům, čísla bankovních karet nebo jakékoli jiné informace, které jsou obvykle přenášeny ve skryté podobě. Potenciálním signálem tohoto útoku pro klienta může být absence označení zabezpečeného HTTPS provozu v prohlížeči. Pro server zůstane takové nahrazení zcela bez povšimnutí, protože nedochází k žádným změnám v provozu SSL.

Otrava mezipaměti ARP

Základem útoku ARP Cache Poisoning je zranitelnost v protokolu ARP . Na rozdíl od protokolů, jako je DNS , které lze nakonfigurovat tak, aby přijímaly pouze zabezpečené dynamické aktualizace, zařízení využívající ARP obdrží aktualizace kdykoli. Tato vlastnost protokolu ARP umožňuje jakémukoli zařízení odeslat paket s odpovědí ARP jinému hostiteli a vyžadovat, aby aktualizoval mezipaměť ARP. Odeslání odpovědi ARP bez generování jakýchkoli požadavků je známé jako odeslání samořízeného ARP. Pokud se jedná o nekalý úmysl, dobře nasměrované samopřesměrované ARP pakety použité tímto způsobem mohou vést k tomu, že si uzly budou myslet, že mluví s jedním uzlem, ale ve skutečnosti mluví se zachycovacím uzlem útočníka [3] .

Scénáře útoku

Útok na systémy veřejného klíče

V případě systému veřejného klíče může kryptoanalytik zachytit zprávy o výměně veřejného klíče mezi klientem a serverem a upravit je, jako v příkladu výše . Aby kryptoanalytik zůstal neodhalen, musí zachytit veškerou komunikaci mezi klientem a serverem a zašifrovat a dešifrovat ji pomocí příslušných klíčů. Takové akce se mohou zdát příliš komplikované na provedení útoku, ale představují skutečnou hrozbu pro nezabezpečené sítě ( elektronický obchod , internetové bankovnictví , platební brána ) [4] .

K zamezení útoků „osoby s aktivním kryptoanalytikem“, která by při přenosu budoucímu odesílateli zpráv nahradila veřejný klíč příjemce, se zpravidla používají certifikáty veřejného klíče .

Vložení škodlivého kódu

Vložení kódu [5] v útoku typu man-in-the-middle se používá hlavně k únosu již autorizované relace, provádění vlastních příkazů na serveru a odesílání falešných odpovědí klientovi [6] .

Útok typu man-in-the-middle umožňuje kryptoanalytikovi vložit svůj kód do e-mailů, příkazů SQL a webových stránek (tj. umožňuje vkládání SQL , vkládání HTML/scriptu nebo útoky XSS ) a dokonce i modifikaci binárních souborů nahraných uživatelem pro přístup k uživatelskému účtu nebo změnu chování programu staženého uživatelem z internetu [6] .

Downgrade Attack

Pojem „downgrade Attack“ označuje takový útok, při kterém kryptoanalytik nutí uživatele používat méně bezpečné funkce, protokoly, které jsou stále podporovány z důvodu kompatibility. Tento typ útoku lze provést na protokolech SSH , IPsec a PPTP .

Pro ochranu před útokem na nižší verzi je třeba deaktivovat nezabezpečené protokoly alespoň na jedné straně; pouze podpora a používání zabezpečených protokolů ve výchozím nastavení nestačí!

Útočník se může pokusit změnit parametry připojení mezi serverem a klientem, když je mezi nimi navázáno spojení [6] . Podle přednášky na konferenci Blackhat Conference Europe 2003 může kryptoanalytik „přinutit“ klienta zahájit relaci SSH1 změnou čísla verze „1.99“ relace SSH na „1.51“ namísto SSH2, což znamená použití SSH V1 [ 7] . Protokol SSH-1 má zranitelnosti, které může kryptoanalytik zneužít. V tomto scénáři útoku kryptoanalytik klame svou oběť, aby si myslela, že relace IPsec nemůže začít na druhém konci (serveru). To způsobí, že zprávy budou předávány explicitně, pokud je hostitelský počítač v režimu vrácení zpět [7] . Ve fázi vyjednávání parametrů relace PPTP může útočník donutit oběť, aby použila méně bezpečnou autentizaci PAP , MSCHAP V1 (to znamená „vrátit se“ z MSCHAP V2 na verzi 1), nebo šifrování nepoužila vůbec. Útočník může donutit svou oběť, aby opakovala fázi vyjednávání parametrů relace PPTP (odeslat paket Terminate-Ack), ukrást heslo ze stávajícího tunelu a útok zopakovat.

Public Communications

Nejběžnějšími veřejnými komunikačními prostředky jsou sociální sítě, veřejné e-mailové služby a systémy pro rychlé zasílání zpráv. Vlastník zdroje, který poskytuje komunikační službu, má plnou kontrolu nad informacemi vyměňovanými korespondenty a podle vlastního uvážení může zprostředkovatele kdykoli bez překážek napadnout.

Na rozdíl od předchozích scénářů založených na technických a technologických aspektech komunikace je v tomto případě útok založen na mentálních aspektech, konkrétně na zakořenění v myslích uživatelů konceptu ignorování požadavků na bezpečnost informací.

Detekce útoků MITM

Kontrola časového zpoždění může v určitých situacích potenciálně detekovat útok [8] . Například s dlouhými výpočty hašovacích funkcí, které se provedou do deseti sekund. K identifikaci potenciálních útoků strany kontrolují nesrovnalosti v době odezvy. Předpokládejme, že dvěma stranám obvykle trvá určitou dobu, než dokončí určitou transakci. Pokud však jedné transakci trvá anomální dobu, než se dostane k druhé straně, může to znamenat zásah třetí strany, který do transakce vnesl další zpoždění.

Aby bylo možné detekovat útok typu man-in-the-middle, musí být také analyzován síťový provoz. Chcete-li například detekovat útok SSL, měli byste věnovat pozornost následujícím parametrům [9] :

Pozoruhodné implementace útoků MITM

Známý nekryptografický útok typu man-in-the-middle provedl router bezdrátové sítě Belkin v roce 2003. Nový model routeru by pravidelně volil náhodné připojení HTTP a přesměroval je na reklamní stránku svého výrobce. Takové neobřadné chování zařízení samozřejmě vyvolalo mezi uživateli pozdvižení, načež byla tato „funkce“ odstraněna z pozdějších verzí firmwaru routeru [10] .

V roce 2011 vedlo narušení bezpečnosti holandskou certifikační autoritou DigiNotar  k podvodnému vydávání certifikátů . Následně byly podvodné certifikáty použity k provádění útoků typu man-in-the-middle.

V roce 2013 bylo oznámeno, že prohlížeč Xpress společnosti Nokia dešifruje provoz HTTPS na proxy serverech společnosti Nokia, což společnosti poskytuje přístup k zašifrovanému provozu  prohlížeče jejích zákazníků ve formě čistého textu . Na což Nokia uvedla, že obsah není trvale uložen a že společnost má zavedena organizační a technická opatření k zamezení přístupu k soukromým informacím [11] .

V roce 2017 společnost Equifax stáhla  své aplikace pro mobilní telefony ze strachu ze zranitelnosti typu man-in-the-middle.

Další významné implementace útoků MITM:

Uvedené programy lze použít k provádění útoků typu man-in-the-middle a také k jejich detekci a testování zranitelnosti systému .

Chyby v nastavení směrování sítě BGP [13] [14] lze použít k přesměrování toků provozu .

Viz také

Jiné útoky

Literatura

  1. ↑ Tanmay Patange. Jak se bránit proti MITM nebo Man-in-the-middle útoku (downlink) (10. listopadu 2013). Získáno 22. listopadu 2017. Archivováno z originálu 24. listopadu 2013. 
  2. ↑ Callegati, Franco; Cerroni, Walter; Ramilli, Marco. IEEE Xplore - Man-in-the-Middle Attack to HTTPS Protocol  //  ieeexplore.ieee.org: journal. - 2009. - S. 78-81 .
  3. ↑ Pochopení útoků typu Man-in-the-Middle - ARP Cache Poisoning . Datum přístupu: 6. prosince 2017. Archivováno z originálu 7. prosince 2017.
  4. ↑ Kryptosystém s veřejným klíčem
  5. ↑ Techtarget Search Security Channel: Běžné injekční útoky . Archivováno z originálu 18. února 2012.
  6. ↑ 1 2 3 Alberto Ornaghi, Marco Valleri, "Man In The Middle Attacks", BlackHat Conference Europe 2003 . Archivováno z originálu 18. února 2012.
  7. ↑ 1 2 Alberto Ornaghi, Marco Valleri, "Man In The Middle Attacks Demos," BlackHat Conference Europe 2003 . Archivováno z originálu 18. února 2012.
  8. ↑ Aziz, Benjamin; Hamilton, Geoff. Detekce útoků typu man-in-the-middle přesným načasováním.  (eng.)  // 2009 Third International Conference on Emerging Security Information, Systems and Technologies : journal. - 2009. - S. 81-86 .
  9. ↑ Síťová forenzní analýza útoků SSL MITM . NETRESEC Network Security Blog . Datum přístupu: 27. března 2011. Archivováno z originálu 18. února 2012.
  10. ↑ Leyden, John . Pomoc! můj router Belkin mě spamuje , The Register  (7. listopadu 2003). Archivováno z originálu 8. srpna 2011.
  11. ↑ Meyer, David Nokia: Ano, dešifrujeme vaše HTTPS data, ale nedělejte si s tím starosti . Společnost Gigaom Inc. (10. ledna 2013). Získáno 22. listopadu 2017. Archivováno z originálu 8. dubna 2019.
  12. ↑ Goodine, Dan SSL spoof bug stále pronásleduje IE, Safari, Chrome; Díky společnosti Microsoft . The Register.co.uk (1. října 2009). Archivováno z originálu 18. února 2012.
  13. ↑ H Birge-Lee, pomocí BGP k získání falešných certifikátů TLS Archivováno 21. července 2017 na Wayback Machine
  14. ↑ Obrana proti BGP Man-In-The-Middle Attacks Archivováno 25. listopadu 2017 na Wayback Machine // Black Hat DC, únor 2009

Odkazy