Názory k článku
EFAIL kritická zranitelnost OpenPGP a S/MIME umožňuje útočníkovi rozšifrovat e-maily
-
BobTheBuilderStříbrný podporovatelPoštovních klientů to postihuje celkem dost, ale:
1) kolik uživatelů používá poštovní klienty (obávám se, že velmi málo)
2) kdo z těch, kdo nepoužívají poštovní klienty, může použít šifrování (obávám se, že skoro nikdo)
3) aby EFAIL fungoval, musí a) se vám nabourat do schránky (to už máte problém mnohem větší) nebo b) odchytit komunikaci mezi servery (při dnešním rozšíření SMTP/SSL to taky nebude snadné)
Takže, z 1) a 2) plyne, že zašifrovaných mailů ve schránkách je opravdu velmi málo a z 3a) že podstatná rizika e-mailu jsou někde jinde (ochrana schránky a počítače).
Opravit to je, samozřejmě, nutné. -
BobTheBuilderStříbrný podporovatel
No ano, ale když takové věci používám (asi pracuji s něčím velmi důvěrným), tak troška paranoie je na místě a ochrání mě:
1) pokud si útočník pohraje s mým mailem, nebude souhlasit DKIM (nebo bude platný, ale pro neplatnou doménu) - řeší doplněk Tunderbirdu DKIM verifier
2) nemám povolené automatické zobrazení vzdáleného obsahu - opět nastavení Thunderbirdu
3) a navíc asi bych měl používat šifrování && podpis, pak zase u pozměněné zprávy narazím na nesoulad (ostatně, pozměněná zpráva je možná někdy ještě horší, než rozšifrovaná)
A ne, přešifrovávat není potřeba, jen opravit chyby v klientech. -
Ad 1) jste nepochopil princip exploitu. DKIM sedět klidně bude. Útočník pošle regulérní mail (a jeho server přiloží správný DKIM podpis), kde multipart/encrypted bude PGP tělo, které útočník potřebuje rozkódovat, před toto tělo dá začátek HTML značky a za tělo dá konec značky. E-mail bude klidně poslán z regulérního mailu přes správný server, takže žádná kontrola DKIMu nepomůže.
Ad 2) Ano, tohle pomůže.
Ad 3) Opět špatně. Část mailu, která je podepsána/šifrována bude nezměněna, tak na žádný nesoulad nenarazíte. Útočník totiž upraví ty části e-mailu, které nejsou podepisovány, ani šifrovány. -
peter (neregistrovaný)
Doporucuji kliknout si na link. Ta zpravicka nevysvetluje presne, o co go.
Utocnik vytvori source-code noveho mailu tak, ze prida prilohu (--BOUNDARY) html obrazek s externi url. K adrese prida prilohu (--BOUNDARY) kod stareho mailu.
<img src=link/--BOUNDARY sifrovanymail">
Uzivatel mail otevre. Renderovaci program se pokusi vsechny prilohy nacist. Desifruje mail a prida k adrese obrazku. Cili, odesle desifrovany mail utocnikovi. Viz obrazek na te strance
https://efail.de/media/exfil1.png -
654 (neregistrovaný)
Jde o sérii slabin a většině jde zabránit. Jednomu z útoků lze zabránit striktním zahazování všech zpráv, u kterých nesouhlasí nebo chybí kontrolní součet (detekce úpravené zprávy je přece jedna ze základních funkcí kontrolního součtu u asymetrické kryptografie). Zacházení s kontrolním součtem/otiskem bohužel není v PGP striktně uvedeno, takže to záleží na implementaci Další slabina je standardní chyba, kdy nějaký vložený kód v textu dělá problémy - konkrétně neukončené uvozovky zdroje obrázku odešlou dotaz na obrázek, v jehož adrese je celý text zprávy (klasická chyba, v minulosti bylo například v IE možné pomocí pokusu o načtení černobílé, 512x512 velké bitmapy, které měla ale ve skutečnosti velikost 1x1, zobrazit v prohléžeči memory dump paměti za obrázkem). Všechny tyto útoky ale vyžadují obejití otisku zprávy!
Ale všechny slabiny mají něco společného. Vyžadují úpravu zprávy, kterou klient sežere i s navijákem. Systémové protiopatření existuje, ale bude to vyžadovat nějaké změny v implementaci PGP. Princip nápravy je jednoduchý:
- defaultně zakázat kód uvnitř zprávy
- povinná, striktní kontrola otisku zprávy
- striktně zahazovat všechno, co není zahrnuto v šifrované části s platným otiskem zprávy, včetně dalších přidaných "přílepků". Zdá se, že soudruzi z NDR hrubě podcenili význam otisku šifrované zprávy. -
Jste nepochopil exploit. Útočník upravuje části mailu, které jsou mimo šfrované/podepisované tělo. Otisky (podpisy) zprávy se jinak běžně kontrolují, to je přece základ každého šifrování/podepisování. (Poslední věta je o ničem)
Chyba je jen v klientech. Správně by měli zahazovat všechny ostatní multipart části, pokud narazí na šifrovanou (nebo podepsanou) část mailu.
