Způsoby, jak hacknout a chránit relaci před krádeží

Většina stránek na internetu je otevřena vnějším vlivům hackerů. I velké a drahé internetové projekty jsou hacknuty: zanechávají stopy nebo odebírají databázi. V důsledku toho trpí vlastník zdroje a také návštěvníci.

Aby se předešlo problémům s hackováním, je během vývoje zapotřebí řada opatření. Během provozu lokality je třeba provádět některá preventivní opatření.

V minulých článcích jsem ukázal, jak jsou servery provozovány, stejně jako servery. Dnes budeme hovořit o odposlechu a ochraně relací hackery.

Relace webu

PHP je pravděpodobně nejběžnějším programovacím jazykem na straně serveru pro webové stránky. V php se relace webu spouští pomocí příkazu session_start(). Před zahájením můžete specifikovat Extra možnosti. Relace obvykle ukládá důležité osobní informace o uživateli: přihlašovací jméno, jméno, heslo, ..

Únos relace

Existují 2 způsoby, jak uložit ID relace: v souborech cookie a v adresní řádek. První možnost je bezpečnější než druhá, ale obě jsou v různé míře hackovatelné. Tenhle typ Hack se nazývá session hijacking.

Nechte identifikátor uložit do adresy URL webu. Přihlášený návštěvník, procházející stránkami vašeho webu, rozhoduje s někým. Při publikování odkazu poskytne odkaz se svým ID relace. Pokud stránka nemá žádné další metody ochrany, pak kliknutím na takový odkaz bude nový návštěvník již přihlášen jako první uživatel, pokud relace ještě neskončila. Pak si na webu dělejte, co chcete, v mezích povolených pravidly.

S cookies je to složitější, ale vše je také docela snadno zachytitelné. Mnoho webů nefiltruje skripty prohlížeče, když uživatelé publikují informace. Potenciální hacker umístí takový skript na stránku. Přihlášený návštěvník navštíví stránku... Skript přečte hodnotu souboru cookie nebo adresní řádek a předá ID relace jinému webu. Druhý web patří hackerovi. Dále je vše jednoduché. Je zfalšován soubor cookie nebo je zadána adresa stránky webu s požadovaným ID relace.

Hackování relací

Při zahájení relace se v dočasném adresáři vytvoří soubory relace. Tyto soubory ukládají informace. Pokud se použije, je dočasná složka pro ukládání relací obvykle sdílena všemi weby na serveru. Dále, určitým způsobem, jsou data relace čtena vlastním skriptem. K tomu musí mít útočník účet na stejném serveru. Výsledkem je, že pokud je v relaci uloženo heslo z webu nebo číslo kreditní karty s kódem cvv, pak to vše užitečné informace padnout do rukou útočníka.

Ochrana proti hacknutí dat relace

  • Uložte relaci do souborů cookie. Těžší vzít.
  • Svažte relaci s IP adresou počítače. Při vstupu z jiné ip se v závislosti na nastavení skriptu vytvoří nová relace.
  • Svažte relaci s uživatelským agentem prohlížeče. Když se přihlásíte z jiného prohlížeče, relace se vynuluje.
  • Šifrovat parametry předané relaci. Pokud útočník získá soubor relace, nebude jej moci číst. I když máte určité dovednosti, je také možné relaci dešifrovat.
  • Uložte ID relací do samostatné složky. V php k tomu existuje příkaz session_save_path($path_to_dir). Stejné nastavení lze zapsat do souboru php.ini. Parametr se nazývá session.save_path.
  • Použijte session_set_save_handler() v php k přepsání způsobu uložení relace. A od PHP 5.4 můžete objekt typu SessionHandlerInterface předat session_set_save_handler().

Mnoho uživatelů si ani neuvědomuje, že vyplněním přihlašovacího jména a hesla při registraci nebo autorizaci na uzavřeném internetovém zdroji a stisknutím ENTER lze tato data snadno zachytit. Velmi často jsou přenášeny po síti v nezabezpečené podobě. Pokud tedy web, na který se pokoušíte přihlásit, používá protokol HTTP, je velmi snadné tento provoz zachytit, analyzovat jej pomocí Wireshark a poté pomocí speciálních filtrů a programů najít a dešifrovat heslo.

Nejlepším místem pro zachycení hesel je jádro sítě, kde provoz všech uživatelů směřuje na uzavřené zdroje (například pošta) nebo před router pro přístup k internetu při registraci na externí zdroje. Nastavujeme zrcadlo a jsme připraveni cítit se jako hacker.

Krok 1. Nainstalujte a spusťte Wireshark pro zachycení provozu

Někdy k tomu stačí vybrat pouze rozhraní, přes které plánujeme zachytit provoz, a kliknout na tlačítko Start. V našem případě snímáme bezdrátově.

Bylo zahájeno zachycení dopravy.

Krok 2. Filtrování zachyceného provozu POST

Otevřeme prohlížeč a pokusíme se přihlásit k libovolnému zdroji pomocí uživatelského jména a hesla. Po dokončení procesu autorizace a otevření webu přestaneme zachycovat provoz ve Wiresharku. Dále otevřete analyzátor protokolů a uvidíte velký počet paketů. Toto je fáze, kdy to většina IT profesionálů vzdává, protože neví, co dál. Ale víme a zajímáme se o konkrétní pakety, které obsahují POST data, která jsou generována na našem lokálním počítači při vyplňování formuláře na obrazovce a odesílána na vzdálený server když v prohlížeči kliknete na tlačítko „Přihlásit se“ nebo „Autorizace“.

Pro zobrazení zachycených paketů zadejte do okna speciální filtr: http.žádost.metoda =="POŠTA"

A místo tisíce balíčků vidíme jen jeden s údaji, které hledáme.

Krok 3. Najděte uživatelské jméno a heslo

Rychlé kliknutí pravé tlačítko myši a vyberte z nabídky Sledujte TCPSteam


Poté se v novém okně objeví text, který v kódu obnoví obsah stránky. Najdeme pole „heslo“ a „uživatel“, které odpovídají heslu a uživatelskému jménu. V některých případech budou obě pole snadno čitelná a nebudou ani šifrovaná, ale pokud se snažíme zachytit provoz při přístupu k velmi známým zdrojům, jako jsou: Mail.ru, Facebook, Vkontakte atd., pak bude heslo zakódováno:

HTTP/1.1 302 Nalezeno

Server: Apache/2.2.15 (CentOS)

X-Powered-By: PHP/5.3.3

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Set-Cookie:password= ; expires=Čt, 07-Nov-2024 23:52:21 GMT; cesta=/

Umístění: login.php

Délka obsahu: 0

Připojení: zavřít

Content-Typ: text/html; znaková sada=UTF-8

Takže v našem případě:

Uživatelské jméno: networkguru

Heslo:

Krok 4 Určete typ kódování pro dešifrování hesla

Jdeme například na stránku http://www.onlinehashcrack.com/hash-identification.php#res a do identifikačního okna zadáme své heslo. Dostal jsem seznam kódovacích protokolů v pořadí podle priority:

Krok 5: Dešifrujte uživatelské heslo

V této fázi můžeme použít nástroj hashcat:

~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

Na výstupu jsme obdrželi dešifrované heslo: simplepassword

S pomocí Wiresharku tak můžeme nejen řešit problémy s provozem aplikací a služeb, ale také se vyzkoušet jako hacker odchytáváním hesel, která uživatelé zadávají do webových formulářů. Můžete také zjistit hesla pro poštovní schránky uživatelé používající jednoduché filtry k zobrazení:

  • Protokol a filtr POP vypadá takto: pop.request.command == "USER" || pop.request.command == "PASS"
  • Protokol a filtr IMAP budou: imap.request obsahuje "login"
  • SMTP a budete muset zadat následující filtr: smtp.req.command == "AUTH"

a serióznější nástroje pro dešifrování kódovacího protokolu.

Krok 6. Co když je provoz šifrovaný a používá HTTPS?

Existuje několik možností, jak na tuto otázku odpovědět.

Možnost 1. Připojte se k odpojení mezi uživatelem a serverem a zachyťte provoz v okamžiku navázání spojení (SSL Handshake). V okamžiku navázání spojení může být klíč relace zachycen.

Možnost 2: Provoz HTTPS můžete dešifrovat pomocí souboru protokolu klíče relace vytvořeného prohlížečem Firefox nebo Chrome. Chcete-li to provést, musí být prohlížeč nakonfigurován tak, aby zapisoval tyto šifrovací klíče do souboru protokolu (příklad založený na aplikaci FireFox) a tento soubor protokolu musíte obdržet. V podstatě musíte ukrást soubor klíče relace pomocí pevný disk jiný uživatel (což je nezákonné). No, pak zachyťte provoz a použijte přijatý klíč k jeho dešifrování.

Vyjasnění. Hovoříme o webovém prohlížeči člověka, kterému je odcizeno heslo. Pokud máme na mysli dešifrování vlastního HTTPS provozu a chceme si to procvičit, pak tato strategie bude fungovat. Pokud se snažíte dešifrovat HTTPS provoz ostatních uživatelů bez přístupu k jejich počítačům, nebude to fungovat – k tomu slouží šifrování a soukromí.

Po obdržení klíčů podle možnosti 1 nebo 2 je musíte zaregistrovat ve WireShark:

  1. Přejděte do nabídky Úpravy - Předvolby - Protokoly - SSL.
  2. Nastavte příznak "Znovu sestavit záznamy SSL zahrnující více segmentů TCP".
  3. "Seznam klíčů RSA" a klikněte na Upravit.
  4. Zadejte data do všech polí a zapište cestu do souboru s klíčem

V minulé roky dochází ke změně trendu ve strategii útoků speciálních služeb na nejdůležitější bezpečnostní protokol pro internet TLS/SSL. Přímý kryptografický útok a hackování je od nynějška nejen extrémní, ale často v rámci něj i zbytečné moderní svět opatření, kde se peníze a finanční zisk stávají hlavní hnací silou.

Vzhledem k důležitosti této problematiky nabízí stránka v rámci řady publikací přehled zabezpečení zásobníku protokolů TLS/SSL a zároveň zvažuje konzistentní a systematické strategie pro oslabování těchto protokolů zpravodajskými agenturami.

Třetina bezpečného provozu na světě je generována kryptografickými prostředky se záměrně oslabeným PRNG?

Odebráno z kanálu

Jako semínko se vraťme k ruskému příkladu – poslednímu soudnímu jednání v případu bývalý majitel platební systém Chronopay Pavel Vrublevsky, obviněný z DDoS útoku proti Aeroflotu.

Podstata klíčové zápletky se scvrkla do toho, že si soud vyžádal interní korespondenci mezi účastníky tohoto trestního řízení, které vedli prostřednictvím osobní účty na Facebooku. Navzdory tomu, že obsahovala nejdůležitější inkriminovanou informaci, zákeřného Američana sociální síť neuposlechla žádost ruské justice a odepřela přístup k soukromé korespondenci občanů Ruské federace. A pak nastává velmi dramatický zlom v tomto příběhu – FSB při výkonu soudního rozhodnutí nezávisle „vytěžuje“ korespondenci těchto občanů.

„Ústřední informační kancelář FSB v souladu se zákonem „O operativně-vyšetřovací činnosti“ provedla nezávislé vyhledání informací z komunikačních kanálů těchto osob a nahrála je na DVD.

Později byla strana obrany skutečně schopna ověřit, že nezbytná osobní korespondence byla „odstraněna ze sítě v plném rozsahu a v rozsahu“ proti vůli Facebooku. Sami obžalovaní v tomto případě zároveň popřeli, že by vyšetřování poskytli svá hesla a sebeusvědčující korespondenci. Na RuNet můžete najít honosné titulky zpráv jako „The Russian FSB Hacked Facebook Servers“, ale neměli byste dělat ukvapené závěry.

Za prvé, všechny komunikační relace s Facebookem probíhají výhradně přes zabezpečený komunikační protokol HTTPS. Za druhé, od posledních kontaktů obžalovaných a toto rozhodnutí soudu (a následně i vyšetřovací činnosti FSB k výkonu tohoto rozhodnutí) uplynulo hodně času. Z jakého druhu „kanálu“ by mohla být tato „údaje z minulosti“ „odstraněna“, pokud se od té doby sami obžalovaní nepřipojili k internetu a jsou vyšetřováni?

Ignorovali tyto přímé otázky položené zástupcům FSB během procesu. Nejzřetelnější verze odpovědi se navrhla sama: HTTPS provoz s touto korespondencí byl FSB předem vyčmuchán / uložen a nějak následně hacknut.

Je zajímavé, že téměř podobný případ byl zaznamenán již dříve v materiálech téhož případu. FSB CIB s odkazem na protokol vyšetřování „uložením a analýzou provozu internetového připojení jednoho z obviněných získalo přihlašovací jméno a heslo z ovládacího panelu botnetu“ (fyzicky umístěného na serveru ve Spojených státech), poté, co který se zmocnil dálkového ovládání tohoto botnetu. Přístup ke stejnému webovému panelu byl tedy ze strany obžalovaných realizován opět výhradně přes šifrované HTTPS spojení v souladu s bezpečnostními opatřeními (např. bez ukládání hesel na jejich lokální počítač).

Konstatujeme tedy existenci problémů s bezpečností HTTPS, citujeme úžasné případy překonání „ochrany“ TLS/SSL ruskými speciálními službami.

modus operandi

Chcete-li prolomit šifrovanou HTTPS relaci, musíte vyřešit dva hlavní úkoly: umět poslouchat (zachycovat) provoz a také umět dešifrovat data zapouzdřená v takto zabezpečeném paketu.

Nebudeme se zabývat prvním bodem, protože speciální služby mají fyzický přístup téměř ke každému kanálu. Ti, kteří sledují nejnovější zprávy ze SORMomostroeniya, si již uvědomují, že v souladu s novým zákonem jsou od 1. července 2014 všichni ruští poskytovatelé povinni instalovat do svých sítí speciální zařízení pro záznam a ukládání jejich tranzitního internetového provozu v plném rozsahu po dobu určitou. dobu minimálně 12 hodin. Kromě toho budou mít bezpečnostní složky přímý přístup ke všem uloženým a tranzitním datovým polím.

Pokud mluvíme o poslechu relací HTTPS, okamžitě zaznamenáme důležitý bod- nutnost poslechu v "aktivním režimu" v některých případech, protože uložený provoz nelze později vždy hacknout. Hovoříme o tzv. režimu progresivního utajení (forward secrecy, FS) pro protokol HTTPS, který zabraňuje možnosti obnovy dat po ukončení komunikační relace (i když útočník může později získat platné klíče webu). Přítomnost takového režimu zavazuje útočníka „kovat železo, dokud je žhavé“ – tedy crackovat data v reálném čase, což je v drtivé většině případů jen stěží technicky možné.

Špatnou zprávou je, že Facebook, stejně jako většina ostatních velkých internetových portálů, nepoužívá režim dopředného utajení, protože vytváří další vážnou zátěž pro již tak přetížený sociální stroj. Kromě toho může použití takových pokročilých algoritmů DH nepříznivě ovlivnit kompatibilitu s některými populárními prohlížeči. Nyní je snadné pochopit, proč podle statistik Netcraft z léta 2013 přibližně 70–99 % připojení SSL pozorovaných v tomto monitorování vůbec nepoužívalo FS.

To znamená, že ve velké většině případů může útočník bezpečně uložit váš HTTPS provoz pro pozdější výběr a hackování (například když se dozví klíč soukromého serveru).

Výše je měření poklesu výkonu na 6jádrovém procesoru webového serveru s povoleným a deaktivovaným DHE. DHE je vybrán jako nejoblíbenější a příkladná implementace Perfect Forward Secrecy. Například Google, jehož služby podporují téměř všechny krypto-inovace a prostředky ochrany svých uživatelů (to je nápadná výjimka z obecné internetové praxe), implementuje krátkodobé („efemérní“) klíče relací PFS založené na ECDHE_RSA. A je to velmi, velmi drahé, věřte mi!

Vzhledem k této poznámce budeme předpokládat, že s odposlechem dopravy je vše víceméně jasné. Nyní se podíváme, co dál s uloženým šifrovaným streamem.

Zdá se, že obecný algoritmus v tomto případě bude vypadat nějak takto: při zachycování zájmového provozu je relace HTTPS zachycena hypotetickými speciálními službami Informační systém obdrží požadavek na vyhledání odpovídajícího klíče serveru do své databáze. Pokud takový klíč není nalezen, je zařazen do fronty k dalšímu výpočtu (cracking). Vezmeme-li v úvahu poznámku o skutečné nedostupnosti možnosti FS, má vždy smysl tiše akumulovat (zapisovat) zájmový provoz bez čekání na odpověď systému o připravenosti / dostupnosti klíče k dešifrování v reálném čase.

S ohledem na zmíněnou databázi od klíče serveru V létě 2013 pak Cnet zveřejnil informace a vzorový dokument žádosti NSA velké internetové společnosti, která si přála zůstat v anonymitě. Podle tohoto zdroje vyšlo najevo, že stejné požadavky obdržely i další velké internetové stránky (Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T atd.). Cnet tyto organizace oficiálně kontaktoval s žádostí o vyjádření. podobný požadavek, ale ve velké většině případů společnosti odmítly takové interakce s NSA buď potvrdit, nebo vyvrátit.

„Znovu si otírám nohy o mýtus, že open source je cesta ke spolehlivosti. Tato chyba v Debian OpenSSL byla téměř dva roky stará."

Tuto zranitelnost bylo skutečně možné uzavřít až po rozruchu v tisku. Samotný projekt Debian nazval situaci s dlouhodobou chybou ve svém úložišti OpenSSL „poněkud zvláštní příběh“.

Pokud mluvíme o notoricky známých hardwarových „záložkách“, pak v poslední době rozkvetly v násilné barvě již na těch nejneočekávanějších místech: od žehliček po kávovary. Takže podle Spiegelu, speciálního oddělení NSA „Special Access Operations“ (Tailored Access Operations, TAO) na dlouhou dobu provedl hromadný odposlech nakoupených nejvíce různé společnosti a země počítačového (nejen) vybavení na cestě od dodavatele k adresátovi. Zachycené zařízení, odeslané zákazníkovi, o nějž má zájem NSA, přitom rychle prošlo tajnou „továrnou“ TAO, kde do něj byl zaveden upravený software nebo „chyby“. Takový zásah do dodavatelského řetězce pro vlastní účely, označovaný zvláštním pojmem „zákaz“, byl samotným NSA hodnocen jako jeden z „nejefektivnějších typů moderních operací“.

Když je povoleno Veškerý provoz (šifrovaný i nešifrovaný) nebo Pouze šifrované agent používá technologii falšování certifikátů SSL k zachycení dat přenášených v zabezpečených webových relacích. Při navazování zabezpečeného spojení se serverem agent nahradí původní certifikát serveru certifikátem se stejným názvem, ale vydaným kořenovým certifikátem agenta. Systém umožňuje používat jak předinstalovaný certifikát, tak ručně vytvořený certifikát s podpisovou autoritou jako root.

Systém umožňuje ručně nainstalovat určité certifikáty pro náhradu při zachycování relací příslušných serverů (webů, programů) propojením certifikátu se serverem.

V některých případech může použití neoriginálního certifikátu znemožnit navázání šifrovaného spojení se serverem. V tomto případě je nutné vyloučit z odposlechu odpovídající servery, tzn. zakázat nahrazování SSL certifikátů při připojování k takovým serverům. Tím se obnoví funkčnost takových stránek nebo programů, ale nezachytí šifrovaný provoz.

Chcete-li nakonfigurovat zachycování provozu SSL:

  1. V okně karty Profil nastavení agentav oblasti úprav profilu vyberte kartu Řízení síťového provozu.
  2. Klepněte na tlačítko Možnosti zachycení SSL a postupujte podle doporučení v aktuálním odstavci.

Výběr režimu spoofingu certifikátu SSL

V okně nastavení vyberte přijatelný režim zachycení:

  • Pro automatické generováníčinidlo SSL kořenový certifikát během instalace do počítače uživatele, vyberte možnost Automatický režim . Vygenerovaný kořenový certifikát bude umístěn do databáze důvěryhodných vydavatelů certifikátů a agent jej automaticky použije k vydání podřízených certifikátů podepsaných ve výchozím nastavení jménem vydavatele Falcongaze SecureTower.

Chcete-li změnit název vydavatele certifikátu, který bude uveden v informacích o zabezpečení připojení, zadejte do pole požadovaný název Jméno v SSL certifikát .

  • Chcete-li použít vlastní certifikát SSL jako kořenový certifikát při zachycování šifrovaného provozu, Vyberte možnost Uživatelský režim. Uživatelský certifikát musí být předem vygenerován a přidán do systémové databáze. Chcete-li zadat certifikát ze systémové databáze, vyberte jeho název v rozevíracím seznamuUživatelský certifikátnebo klikněte na tlačítkoUživatelské certifikáty propřidání souborů certifikátů a soukromých klíčů do systémové databáze.

V okně, které se otevře, klikněte na tlačítko Přidat certifikát a určete soubory certifikátu a klíčů jedním z následujících způsobů:

  1. Chcete-li vygenerovat nový certifikát, klikněte na tlačítko Vygenerovat certifikát. V okně, které se otevře, zadejte název nového certifikátu, dobu jeho platnosti a zadejte cesty, kam budou uloženy soubory nově vytvořeného certifikátu (*.cer) a soukromého klíče (*.pvk). Klikněte na tlačítko Generovat.

  1. Pokud chcete přidat certifikát, který byl dříve vygenerován ve formátu PFX, klikněte na tlačítko Převést z certifikátu ve formátu PFX. Zadejte cestu a heslo k souboru certifikátu ve formátu PFX a také cestu k souborům certifikátu (*.cer) a soukromého klíče (*.pvk), na které chcete převést původní soubor. Kliknutím na tlačítko Převést dokončíte převod.

V okně klikněte na Další Přidání uživatelských certifikátůpokračovat v postupu dodatky . V okně, které se otevře, zadejte jedinečný název, kterým bude přidaný certifikát podepsán, a komentář (volitelné).

Klikněte na Hotovo k dokončení procesu. Certifikát bude přidán do databáze uživatelských certifikátů systému SecureTower. Klikněte OK pro dokončení sčítání.Přidáno vlastní certifikát bude automaticky umístěn agentem do databáze důvěryhodných tvůrců (pokud tak neučinil dříve správce sítě) a poté bude použit k vydání podřízených certifikátů.

Poznámka.

Při použití uživatelského režimu se doporučuje, aby správce sítě distribuoval uživatelský certifikát všem počítačům v síti, které používají skupinové zásady nebo ručně. To zajistí úspěšné ověření certifikátu. V opačném případě bude certifikát automaticky přidán agentem do úložiště důvěryhodných certifikátů.

Navázání SSL certifikátu na server

Chcete-li určit shodu "server-certifikát", klikněte na tlačítko Vazby certifikátůa postupujte podle následujících pokynů:

  • Chcete-li se vázat na konkrétní kořenový certifikační server na kartě Kořenové certifikáty, zmáčknout tlačítko Přidejte certifikát webu. Zadejte název hostitele ( Doménové jméno), ke kterému budou vydány podřízené certifikáty a ke kterému bude vázán kořenový certifikát v poli Název hostitele (IP adresa). Z rozevíracího seznamu polí vyberte jeden z předinstalovaných kořenových certifikátů Kořenový certifikát nebo klikněte na tlačítko Uživatelské certifikáty přidat a zadat soubory certifikátu a soukromého klíče na počítači uživatele.
  • Chcete-li svázat již existující certifikát s konkrétním serverem, vyberte kartu Uživatelské certifikáty. Agent nebude generovat nové podřízené certifikáty pro servery uvedené na této kartě, ale použije certifikáty určené uživatelem pro procedury nahrazování. V okně, které se otevře, zadejte do pole Název hostitele (IP adresa) název hostitele (název domény), ke kterému bude certifikát vázán. Vyberte jeden z certifikátů v rozevíracím seznamu pole Certifikát : (pokud již byly certifikáty přidány dříve) nebo klikněte na tlačítko Uživatelské certifikáty pro výběr uživatelských certifikátů ze seznamu nebo pro přidání a určení souborů certifikátů a soukromých klíčů v počítači uživatele.

Poznámka.

K vyplnění pole Název hostitele (IP adresa) použití IP adresy hostitele je povoleno, ale pouze v případech, kdy jméno hostitele nebylo během připojení určeno a je známa pouze IP adresa.

Vyloučení serverů ze zachycování šifrovaného provozu

Chcete-li pracovat s výjimkami z procesu falšování certifikátu, klikněte na tlačítkoVýjimky serveru SSL.

Okno správce výjimek zobrazuje seznam serverů (hostitelů), které jsou standardně vyloučeny z procesu nahrazení. Chcete-li přidat nové vyloučení, klikněte na tlačítko Přidejte výjimku.

Do vstupního pole dialogového okna, které se otevře, zadejte název serveru (hostitele) (například accounts.google.com), rozlišují se malá a velká písmena a klikněte na tlačítko Přidat. Systém vám umožňuje používat vkládání názvů maskou (jsou povoleny znaky ? a *, například použití *.microsoft.* zabrání duplicitním prostředkům společnosti Microsoft v seznamu vyloučení) k vyloučení zdrojů stejné rodiny. Zadané jméno se objeví v seznamu vyloučení.

Dále musíte vybrat režim vyloučení: Spoof certifikáty pouze pro SSL servery uvedené výše nebo Náhradní SSL - certifikáty pro všechny servery kromě výše uvedených. V prvním případě systém podvrhne certifikáty pouze pro servery uvedené v seznamu výjimek (a bude tedy schopen zachytit odpovídající provoz). U všech ostatních nebudou certifikáty podvrženy a zachycení odpovídajícího šifrovaného provozu nebude možné. Ve druhém případě systém nahradí certifikáty pro všechny servery kromě těch, které jsou uvedeny v seznamu výjimek.

Chcete-li provést další operace s výjimkami, postupujte podle příslušných doporučení v odstavci

Ukážu a řeknu vám, jak používat nástroj sslstrip k zachycení dat přenášených přes zabezpečené připojení SSL.
Obslužný program sslstrip v mém příkladu (po provedení ARP spoofingového útoku na oběť) zachytí požadavek webového klienta oběti o navázání zabezpečeného připojení SSL a přinutí jej použít nezabezpečený protokol HTTP. Dále se jen podívám na to, co oběť dělá, aniž bych věnoval pozornost tomu, že nečte poštu přes HTTPS, ale přes HTTP.

Uvidíte, jak snadné je organizovat útoky typ MITM na SSL pomocí techniky arp-spoof a programu sslstrip.

V mém příkladu je obětí virtuální stroj s IP 10.10.11.163 (běžné auto s Windows), PC, ze kterého útočím, je 10.10.11.85 s nainstalovaným Kali OS a s sslstrip (tato utilita je předinstalovaná v pentester Kali\BackTrack linuxové distribuce). Mezi námi je brána s IP 10.10.11.1.

1. Když oběť zadá gmail.com, je odeslána na adresu https://gmail.com a to je normální. Hesla a přihlašovací údaje k poště oběti přirozeně nevidíme jasně.

2. Povoluji směrování provozu na PC pomocí Kali:

echo "1" > /proc/sys/net/ipv4/ip_forward

a nakonfigurujte iptables tak, aby veškerý provoz http směřoval na port 81:

iptables -t nat -A PŘEDMĚROVÁNÍ -p tcp --destination-port 80 -j PŘESMĚROVÁNÍ --to-port 81

arpspoof -i eth0 -t 10.10.11.163 10.10.11.1

nyní provoz oběti prochází mým autem a (podle mého pravidla iptables) je přesměrován na port 81.

3. Spusťte sslstrip

sslstrip -a -l 81 -w /root/Desktop/ssllog.txt

tím se vytvoří soubor protokolu přímo na ploše a začne se do něj zapisovat zachycený http provoz (ve skutečnosti bude HTTPS zachycen, ale bude odstraněn) No, obecně začínám sledovat tento soubor na konzoli:

tail -f /root/Desktop/ssllog.txt

4. Oběť jde na jeho poštu

Pro čtení pošty si oběť jako vždy vleze do MS Exploreru (hehe) a zadá tam gmail.com. Ale z nějakého důvodu prohlížeč nepřesměruje oběť na https (v adresním řádku http)! Obrázek níže ukazuje, co oběť uvidí na poslední chvíli, než zjistím její heslo a přihlašovací jméno.

Oběť klikne na "Přihlásit se" ... a v mém okně, kde byl zobrazen zachycený provoz, vidím následující:

Jak vidíte, heslo 1q2w3e4r5t6y...

Chcete-li se vyhnout hrozbám spojeným se zachycením začátku připojení SSL, musíte:
- nepoužívejte gadgety v nedůvěryhodných sítích, i když je to velmi nutné (padouch může s mnohem vyšší pravděpodobností zařídit MITM, řekněme, na letišti instalací podvodného bezdrátového přístupového bodu než rozbitím firemní síť vaše organizace);
- šifrovat poštu pomocí symetrických šifrovacích protokolů (píšu a přemýšlím o PGP);
- platit správci normální plat, aby neměl chuť takto špehovat vaše zaměstnance;
- sledovat tabulku ARP a používat hardware / software, který monitoruje podbny útoky;
- pravidelně aktualizovat software z důvěryhodných právních zdrojů.

Mějte na paměti, že tento článek ilustruje, co je zákonem zakázáno, a příklady v něm jsou uvedeny, aby ukázaly, jak snadné je napadnout SSL pouze pro vzdělávací účely.