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?
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?
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í).
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").
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.
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.