Postfix, SSLv3, Avast a man in the middle

23.1.2015 20:19 | Přečteno: 2310× | | poslední úprava: 23.1.2015 20:19

Příběh o tom, jak jsem odhalil temné tajemství nadnárodní korporace. Paranoia a spiknutí. Temný pokoj osvětlený jen září monitoru. Nervy tečou (bohužel mně). Webový a mailový štít Avastu. MITM.

Určitě to taky znáte, pátek večer, za hodinku nebo dvě je čas končit s prací, a počítač si postaví hlavu. Většinou je chyba mezi židlí a klávesnicí, ale ne vždycky.

Mám doma nainstalované Windows (jako zavaděč na hry jsou stále nepřekonané), ale protože mě živí administrace Linuxu a z Windows se mi špatně pracuje, mám taky virtuální stroj a v něm Arch Linux. Ve čtyři odpoledne jsem se pustil do práce s Postfixem, cílem bylo zakázat SSLv3, protože zákazník si nechal udělat pentesting a tohle byla jedna z položek. Sice mám pochybnosti o smyslu bezpečného TLS když se pomocí MITM dá zahodit příkaz STARTTLS a taky když se používá snakeoil certifikát, ale o tom tenhle zápisek není.

Poměrně rychle jsem našel popis jak to udělat. Protože rozumný člověk necopypastuje všechno co najde na Internetu hned do konfigurace na produkci, otevřel jsem manuál, zorientoval se v různých smtpd_tls_mandatory_protocols, smtp_tls_protocols a podobně, nasypal to do Postfixu a řekl si že bych to měl radši otestovat. Píšu

já@doma% openssl s_client -host HHH -port PPP -starttls smtp -sslv3

a vyskočí Avast z hostitelských Windows, že certifikát je self-signed (aby nebyl) a že je to fuj. Přidávám výjimku, a dostávám informaci že spojení navázáno přes SSLv3. WTF?

Jasně, to bude chyba v konfiguraci. Dělám to prvně, někde jsem určitě zapomněl nějaké to _mandatory_ nebo vykřičník. Otvírám konfigurák, manuál, koukám na ty čtyři řádky a nevidím chybu. Už je pět a začínám toho mít plné zuby. Tak trochu ze zoufalství zkouším

já@server% openssl s_client -host HHH -port PPP -starttls smtp -sslv3

a dostávám nulovou šifru (STARTTLS neprošlo). WFT WFT? z localhostu to funguje a ode mě z domu ne? Ověřuju jestli funguje TLS (ano, z obojího), SSLv2 (doma ne) a zjišťuju že Debian asi kompiluje OpenSSL bez podpory SSLv2, protože OpenSSL nezná parametr -ssl2 i když je v manuálu.

Pomalu propadám beznaději a paranoie (že by na mě vážně někdo dělal MITM? Copak prsty NSA sahají až sem? Mohly by), a pak si vzpomenu na to co jsem četl o korporacích které instalují na svoje počítače certifikáty aby mohly kontrolovat jestli někdo přes SSL/TLS neposílá ven firemní tajemství. A taky na tu hlášku Avastu. Že by Avast dělal MITM na mě? Vypínám Avast a... taky že jo. Najednou SSLv3 nefunguje. Sprostě nadávám, označuju jako vyřízené a končím s prací.

Po pauze na nákup jídla a pití sedám k Internetu a jdu zjistit jak to sakra funguje. Takže:

• Avast má vlastní certifikační autoritu jménem "avast Web/Mail Shield Root". Její certifikát nainstaloval do všech prohlížečů a do systémového úložiště. Při navázání šifrovaného spojení vygeneruje nový certifikát podepsaný touto autoritou a ten předloží prohlížeči. Sám pak dělá man-in-the-middle.
• Jediné oficiální informace které jsem našel jsou zápisek na fóru Avastu o nových funkcích vývojové verze
• Certifikát nainstalovaný do systému má překvapivě velká oprávnění. Bohužel jsem si ho nevyexportoval, ale vybavuju si že se dal použít k autorizaci nahrání kódu do jádra, podepisování Windows Update, jako časové razítko a další věci spolehlivě nesouvisející s HTTP nebo SMTP.
• MITM se dá vypnout pro HTTPS bez toho že by se vypnulo testování HTTP, ale to samé neplatí pro SMTP.
• Vypnutí MITM neodinstaluje certifikát. Zapnutí MITM neobnoví všechny možnosti certifikátu; kupodivu se zapnulo Windows Update ale ne Ověření serveru.
• Nevíme jak byl certifikát vygenerován. Především nevíme, kdo k němu má ještě klíč, nebo ho může odvodit, třeba kvůli omezené entropii klíčů.

Bezpečnost vždycky zahrnuje kompromisy. Je pro mě přijatelné že Avast může hledat malware v zašifrovaných datech, za cenu toho že vidí do mých dat (a možná není sám)? Ještě si to budu muset rozmyslet. Moje důvěra je ale celkem otřesená.        

Komentáře

[Jendа]

Sice mám pochybnosti o smyslu bezpečného TLS když se pomocí MITM dá zahodit příkaz STARTTLS

Ale rozumný mailový klient zařve.

Moje důvěra je ale celkem otřesená.

Mně to přijde korektní, kdyby to dělal dobře. Bohužel jsem viděl právě situaci, kdy kvůli tomu starttls přestalo fungovat (nezkoumal jsem proč).

[trekker.dk]

Mně to přijde korektní, kdyby to dělal dobře.

Nejčastější řešení problému "nic jsem neměnil a přestalo mi fungovat odesílání pošty" - podívat se do nastavení antiviru a obnovit tam pravidlo povolující připojení na poštovní server (a které se smazalo při aktualizaci toho antiviru.)

[unavensluncem]

Scanovani HTTPS je podle me dobra a dokonce nutna feature... Malwaru ktery pouziva https je mnoho... Ono jak jinak bys takovou vec delal? Uprimne, jakykoliv program co si nainstalujes (coz znamena admin prava), navic jeste s drivery, si proste muze delat co chce - takze instalujes veci kterym veris ne?

[Petr Tomášek]

Pluginem/rozšířením do prohlížeče?

[Martin Tůma]

Jediné oficiální informace které jsem našel jsou zápisek na fóru Avastu o nových funkcích vývojové verze

Oficiální popis je třeba v manuálové stránce u linux verze nebo v techinfu pro OS X verzi. Windows verze funguje principielně stejně. Pokuď nejdou informace dohledat, tak bych to spíš přisuzoval "korporátnosti" Avastu, nebo prostému faktu, že to nikdo nesepsal, než tomu, že by se to nějak "tajilo" (od toho jsou v Avastu jiné věci ).

[Filip Jirsák]

Mne překvapuje, že to ještě někoho překvapuje. Antiviry vždy dělaly ty největší bezpečnostní prasárny, vždy používají stejné postupy, jako viry a útočníci. Akorát autoři antivirů se tváří, že oni jsou ti hodní. Kde o tom můžu rozhodnout, tam antivir není, a funguje to lépe, než počítače s antiviry.

[trekker.dk]

Ve čtyři odpoledne jsem se pustil do práce s Postfixem, cílem bylo zakázat SSLv3, protože zákazník si nechal udělat pentesting a tohle byla jedna z položek.

Tyhle automatické udělátory jsou srandovní. Detekujeme SSLv3 - hlásíme jako problém. Pokud vím, nikdo zatím nepřišel na způsob, jak zranitelnost SSLv3 zneužít při odposlouchávání SMTP.

Sice mám pochybnosti o smyslu bezpečného TLS když se pomocí MITM dá zahodit příkaz STARTTLS a taky když se používá snakeoil certifikát, ale o tom tenhle zápisek není.

Pokud vím, tak Postfix (v pozici klienta) podporuje DANE - když cílový server má TLSA, zahození STARTTLS při MITM způsobí, že se Postfix nepokusí ten mail doručit.

[Lyco]

Pokud vím, tak Postfix (v pozici klienta) podporuje DANE - když cílový server má TLSA, zahození STARTTLS při MITM způsobí, že se Postfix nepokusí ten mail doručit.

Jó, kdyby tak byl DNSSEC široce rozšířený, to by bylo...

[Max]

To je známá věc, jeden z důvodů, proč tyhle blbosti v AV vypínám. Na příchozí poštu mám AV na mailserveru a zakazuji exe i v archivech, takže k nám se nic dostat nemůže. Další filtry jsou na proxyně. Vždy dumám, jak zapnutí na AV ponechat a nakonec dojdu k tomu, že to vypnu, protože ty problémy za to nestojí.
Zdar Max

[Martin Tůma]

Další filtry jsou na proxyně.

Docela by mě zajímalo, jak filtrujete zabezpečená spojení (HTTPS) na proxy bez použití MITM?

[Max]

U https se filtrují jen linky (povolené url).
Zdar Max

[Martin Tůma]

Stále mi uniká, jak se k těm URL dostanete. Pokuď si tedy pod pojmem URL nepředstavujete doménové jméno/IP adresu... (to je ale pro jakékoliv smysluplné filtrování zcela nedostačující informace).

[Josef Kufner]

Doména se přenáší nešifrovaně, šifrování je zahajováno až po ní, aby fungovaly šifrované virtualhosty na jedné IP adrese (SNI)

[Martin Tůma]

Řekl bych, že to že lze získat doménové jméno/IP adresu je zřejmé už z toho mého příspěvku. Já se ale ptám na URL o kterém se tady hovořilo.

[Lyco]

Podle mého názoru je lepší nefiltrovat. Zodpovědný uživatel je nejlepší filtr proti běžným útokům, a proti APT (advanced persistent threat) stejně antivir nepomůže.

Když už, tak kontrolovat maily když se ukládají na disk jako každý jiný soubor. To samozřejmě nechrání proti stack overflow při přijímání mailu, ale uložit soubor na disk by měla být dost jednoduchá operace na to aby se to "nedalo pokazit".

[trekker.dk]

Zodpovědný uživatel

A kde se nechá sehnat?

[Filip Jirsák]

Taky nechápu, proč je někdo přesvědčen, že někdo stáhne vir zrovna přes e-mail nebo přes HTTPS, a ostatní kanály ho nezajímají. Když už se má něco kontrolovat, není lepší kontrolovat soubory na disku? Taky mi není jasné, proč ti uživatelé mají taková práva, že mohou něco pokazit.

[Max]

1) Z user space bez admin práv můžeš : zašifrovat veškerá data na sdílených discích, kam má uživatel přístup (viz ten šmejd z nedávné doby, máme s ním i osobní zkušenosti), dále z user space můžeš v klidu dělat DoS na nějaký server. Taktéž z userspace můžeš hledat další zranitelnosti na síti.
2) Když jsou lidi za proxynou a mají zakázány flashky apod., tak odkud si asi tak mohou zavirovat PC, když né z mailu, nebo http?
3) veškerý šmejdy, se kterými jsme se setkali, připutovaly mailem. AV nemá nikdy aktuální db a úspěšnost detekece havěti, co není v db, je hodně mizerná.
Naše proxy má hodně bohatý rejstřík blacklistů a na mailové gateway už konečně můžeme blokovat spustitelné přílohy, co jsou zabaleny v archivech. Ze zkušenosti je tato primitivní prevece velmi účinná.
Řešit soubory na disku, to už je pozdě, protože viz AV a neaktuální databáze.
V další fázi ochrany pak může nastoupit autodetekce anomálií na síti, což třeba dělá FlowMon, nebo NetFlow - Nfsen apod. Ale to už je také docela pozdě, ale aspoň člověk ví, co se mu děje na síti a čím dřív něco detekovat, tím líp.
Zdar Max

[Filip Jirsák]

Ad 1) Zašifrovat data na sdílených discích, nebo je smazat, můžu i bez viru. K tomu šifrování asi budu potřebovat nějaký program, což je otázka, proč ke spuštění takového programu má uživatel práva. K mazání asi uživatel program má, může to udělat i omylem, takže se tenhle problém stejně musí nějak řešit. K DoS a hledání zranitelností opět uživatel potřebuje nějaký program, je otázka, proč má práva ke spuštění takového programu.

Ad 2) Třeba z mailu nebo HTTP, co antivir neodhalí. Třeba protože to bude v zaheslovaném archivu. Opět nevidím problém v tom, že uživatel odněkud něco stáhne, vidím problém v tom, že má právo to spustit.

Ad 3) Nevidím důvod, proč kvůli tomu zasahovat do SMTP komunikaci, navíc do odchozí. Hlavně opět vidím problém v tom, že něco, co přijde e-mailem, může být považováno za spustitelnou přílohu.

[Max]

1) řeší se tu průnik, popř. nakažení nějakou potvorou, né uživatel sebevrah, který chce být vyhozen.
3) do odchozí se nezasahuje, to by bylo zbytečné.
Celý tvůj argument je tedy o tom si pohlídat, co uživatel může spouštět a co ne, což je samozřejmě pěkná téze. Otázkou pak je, co se adminovi více vyplatí, zda si držet seznam povolených app a průběžně aktualizovat s tím, že bude mít pak nehorázné drbačky s aktualizacemi různých webových aplikací, co instalují do pc netframework klietnské části apod. a nejen těch, třeba u nás se mění binárky programů několikrát za den (pořád se vyvíjí a nasazuje). Nebo, zda nebude lepší prostě udělat preventivní opatření, co jsem popsal. Rozhodující faktor asi nebude dosáhnout maximální bezpečnosti, ale nějakého rozumného kompromisu zabezpečení s co nejmenší náročností na správu.
Kdo by chtěl maximální zabezpečení, tak by asi musel přistoupit ke všemu, protože i třeba taková politika povolených app. apod. nezabrání tomu, aby uživatel případný bordel v mailech apod. rozesílal dál,i mimo firmu, což je možná ještě horší, než kdyby to zůstalo doma.

Přiznám se, že nasazení politik ohledně povolených app nemám a nemám s tím tedy takové zkušenosti. Ty s tím zkušenosti máš? Zajímalo by mně hlavně to, na jak pestrobarevném prostředí to máš nasazeno a jak náročná je správa?
díky
Zdar Max

[Filip Jirsák]

K tomu, aby člověk smazal soubory na sdíleném úložišti, stačí chvilková nepozornost. K tomu, aby spustil nějaký vir, je potřeba té nepozornosti mnohem víc.

Pokud se do odchozí pošty nezasahuje, pak nechápu, k čemu tam je únos SMTP spojení a podvržené certifikáty.

Připadá mi lepší, když admin kontroluje, co mohou uživatelé spouštět, než když se poruší všechny možné i nemožné bezpečnostní bariéry s úmyslem, že ale tohle porušení dělají hodní hoši a je to ku prospěchu věci. Já tomuhle nevěřím a myslím si, že když něco dokáží prolomit hodní hoši, dokáží to padouši ještě snáz.

Navíc tím učíte uživatele, že mohou stahovat z internetu, co je napadne, protože pokud to bude něco škodlivého, zablokuje to antivir. Učíte je, že na nějaké kontroly DNSSEC v prohlížečích nebo ověřování certifikátů mají kašlat, protože je stejně všechno falešné. A to, co se naučí, pak aplikují i jinde, třeba na svých domácích počítačích.

Měl jsem to v prostředí, které bylo z hlediska softwaru jednotné, byly jen rozdíly ve verzi OS (myslím že Windows NT 4.0 a 2000 nebo 2000 a XP) a verzi MS Office, ostatní snad bylo shodné. A byla povolená cesta ke spustitelným aplikacím, už si nepamatuju, zda bylo možné zadat prefix, a vše pod ním už bylo povolené, nebo zda se skriptem vypsaly všechny programy z C:\Windows a C:\Program Files. Ale pak se to myslím přestalo používat, protože se tam začalo učit programování a tím pádem nebylo možné zakázat spouštění neznámého software. Ale je možné, že jsem měl jenom štěstí na uživatele, kteří chápali, že nejhorší, co může nějaký vir v síti udělat, je to, že smaže jejich data. A je také pravda, že tenkrát té havěti bylo míň. Nicméně pořád si myslím, že pokud má ten uživatel k dispozici aktuální software, a přesto spustí nějaký vir, je otázkou především to, co na tom počítači vlastně dělal.

[Jendа]

K tomu, aby člověk smazal soubory na sdíleném úložišti, stačí chvilková nepozornost. K tomu, aby spustil nějaký vir, je potřeba té nepozornosti mnohem víc.

Na běžném Linuxu je to bohužel dost jednoduché. Mně se to stalo když jsem používal GTK archivátor Squeeze. Klikl jsem na .py v zipu a zeptalo se to, jestli to chci rozbalit nebo otevřít. Dal jsem otevřít samozřejmě v očekávání, že se zobrazí textový editor. Ne, samozřejmě to spustilo Python.

Nebo třeba stačí bouchnout v mc do entru nad souborem který má X práva (protože ho tak někdo rozbalil, byl tak na externím disku nebo se tak odněkud zkopíroval).

V prvním případě vám nepomůže ani mountovat s noexec, v druhém ano, ale to nemusí být vždy možné, v podstatě kdykoli když si uživatel v $HOME kompiluje.

[Filip Jirsák]

V obou případech jste ale nejdřív někde musel ten vir získat. Což je řekl bych ta největší komplikace.

[Jendа]

V prvním případě jsem stahoval nějaké příklady na Python (potenciálně nedůvěryhodný web, proto jsem si taky chtěl ten zdroják přečíst než to spustím), ve druhém to byla cizí flashka.

[Max]

Jednak už od začátku píšu, že jsem proti filtraci odchozích spojení, nelíbí se mi řešení avastu apod. Dále, dostat vir do pc je jednoduché úplně stejně jako omylem něco smazat na síťovém disku. Resp. ze zkušenosti vím, že případ s virem je častější. A opravdu moc nezáleží na uživateli. Je tolik technik, jak uživateli něco podvrhnout, že není možné, aby byl úplně bdělý nonstop. Např. běžně lidé vyřizují třeba 100 mailů za den, někdy i více. Dost z nich jich má přílohu. Dost z nich je příloha zabalená. Když přijde mail od dhl.com s nápisem invoice v zipu, tak uživatel instinktivně kliká a windows easy featurky to jen zjednodušují. Osobně se považuji za obeznámeného a opatrného člověka, ale musím připustit, že jsem omylem také už něco spustil. Proto je dobrá prevence na všech frontách. Jinak co si tak pamatuji, tak AV u nás vždy zklamal. Vesměs toho nikdy moc nezastavil.
Jinak veškerá havěť, co se kdy u nás objevila, tak přišla přes mail.
Zdar Max

[Filip Jirsák]

Na popisu na začátku vlákna mne nejvíc dráždil útok na HTTPS a SMTP/TLS komunikaci. K tomu z vašeho popisu nevidím důvod - používáte to?

[Max]

Ne, komunikace směrem internet je zakázána a je povolena jen proxyna. Na proxyně se aplikují různé acl, blacklisty apod. V případě https je blokována adresa serveru, v logu tedy není vidět úplně celá url, ale jen doména.
Zdar Max

[trekker.dk]

Tak jak je to? V #9 píšete, že se u https filtrují jenom linky (url), tady zase, že je blokována jenom adresa serveru. A v obou případech - jak se ta proxy k těm informacím bez MITM dostane? U HTTPS bez MITM nevidí ani URL, ani doménu (pokud si ji nevytáhne ze SNI)

[Martin Tůma]

Tipoval bych, že od začátku myslí hostname/IP adresu, jenom tomu říká URL...

IP adresa/hostname je ale v reálném světě prakticky k ničemu, pokuď tedy vynecháme totalitní režimy (ať už státní, či korporátní - domácí uživatelé většinou úplně netouží po tom, mít Internet filtrovaný Čínskou vládou, Maxem, Filipem Jirsákem nebo jinou "vrchností"...), kde se dostanete jenom na marginální množinu povolených domén. V reálném Internetu je potřeba znát skutečné URL a většinou i data samotná, aby se dalo hovořit o nějaké účinnosti detekce malware.

[Max]

Ahoj, moje chyba, špatně jsem se vyjádřil. Url se filtrují jen u http, u https jen doména/IP.
Zdar Max

[Martin Tůma]

Taky nechápu, proč je někdo přesvědčen, že někdo stáhne vir zrovna přes e-mail nebo přes HTTPS, a ostatní kanály ho nezajímají.

Ostatní kanály (mimo mail a web) jsou co se šíření nákaz týče naprosto marginální.

Když už se má něco kontrolovat, není lepší kontrolovat soubory na disku?

To je samozřejmě základ, ale nestačí to. Zejména co se webu týče existuje spousta scénářů, kdy soubor s nákazou vůbec nemusí existovat (síť -> paměť).

Taky mi není jasné, proč ti uživatelé mají taková práva, že mohou něco pokazit.

On ten xkcd strip vůbec není mimo realitu...

[Filip Jirsák]

Spousta scénářů? Které? Mne napadají pouze bezpečnostní chyby v prohlížeči nebo v jeho pluginech. Já se spíš bojím bezpečnostních chyb v antivirových programech, které mají typicky mnohem větší práva, než webový prohlížeč.

[Martin Tůma]

Které? Mne napadají pouze bezpečnostní chyby v prohlížeči nebo v jeho pluginech.

Přesně ty.

[mimi.vx]

tak bez podpory ssl2 kompiluji openssl uz roky vsechny rozumne distribuce a ssl3 povypinali vsichni loni v zime ...

[David Watzke]

FYI: nahlásil jsem to avastímu supportu a požádal jsem o přidání informací o tomto chování do dokumentace / nápovědy (prostě do nějakého dokumentu, který při instalaci bude uživateli nabídnut k přečtení).

[Lyco]

Dík, občas se hodí mít známé na vysokých místech :). jestli můžeš, tak je popostrč taky k tomu aby zkontrolovali ten certifikát. Vážně pochybuju že scanování https vyžaduje zavádění kódu do jádra a spol. A taky by to chtělo jednoduchý způsob jak ten cert. odstranit - třeba když tu funkci vypnu.

[Lol Phirae]

Dík, občas se hodí mít známé na vysokých místech :)

http://feedback.avast.com/ https://forum.avast.com/

Vážně to čtou a reagují.

[David Watzke]

Není zač. Mimochodem, support avastu je dostupný pro všechny a je tam sekce i pro připomínky, když se k tomu proklikáš.

[Martin Tůma]

A taky by to chtělo jednoduchý způsob jak ten cert. odstranit - třeba když tu funkci vypnu.

Proč? Pokuď se někdo dostane k unikátnímu privátnímu klíči na vašem počitači (který je dostupný pouze s "admin" právy) aby s ním podepsal nějaký svůj certifikát, tak už opravdu není důvod se obávat nějakého dalšího průniku/úniku dat - vše už je dávno ztraceno... A pokuď nevěříte Avastu jako takovému, tak vypínat zrovna tuto funkci, když přes jaderné moduly má přístup ke kompletní paměti vašeho počítače ( kterou si může kdykoliv poslat "domů") i bez ní je jenom ztráta času...