Исследователи раскрыли (https://efail.de/) (PDF (https://efail.de/efail-attack-paper.pdf)) детали уязвимости системах шифрования электронной почты, не дожидаясь намеченного времени публикации. В целом, предположения (https://www.opennet.me/opennews/art.shtml?num=48596) разработчиков GnuGP оказались верными, а предупреждение о критичности слишком преувеличенными. Предложено два варианта MITM-атаки на почтовые клиенты с поддержкой HTML, которые автоматически загружают данные из внешних ресурсов (например, картинки и CSS).Первый вариант атаки производится через модификацию транзитного сообщения, в которое подставляется обращение к внешниму ресурсу при помощи тегов "img" или "style", подставляемых в незашифрованные части HTML-писем (MIME-заголовки). Обращающийся к внешнему хосту атакующего тег открывается до начала шифрованного MIME-блока, а закрывается после него (см. пример ниже).
Почтовый клиент с проблемным MIME-парсером при открытии письма дешифрует шифротекст, а затем разбирая HTML отправляет уже расшифрованный текст в составе подставленного атакующими тега. Проблема проявляется только в почтовых клиентах, которые объединяют содержимое всех MIME-частей multipart-сообщения, смешивая шифрованные и незашифрованные части. Например, такое поведение свойственно Apple Mail, iOS Mail и Thunderbird.
Второй вариант атаки отталкивается от уязвимостей в спецификациях S/MIME и OpenPGP. В случае S/MIME атакующий может организовать дешифровку нескольких email, отправив специально изменённое email-сообщение жертве. Для PGP без поддержки MDC атаку совершить сложнее и успешной оказываются только треть попыток, так как перед шифрованием в
PGP открытый текст сжимается. Как и в первом варианте в сообщение вставляется HTML-тег, обращающийся к подконтрольному атакующему хосту.Атака базируется на подмене блоков шифротекста, манипулируя изначально известными блоками данных при использовании режимов CBC (https://ru.wikipedia.org/wiki/%D0%A0%D0%... и CFB (https://ru.wikipedia.org/wiki/%D0%A0%D0%...Зная открытый текст, в режиме CBC атакующий может выборочно изменить блоки.
В большинстве случаев при использовании S/MIME в составе исходного текста присутствует строка "Content-type: multipart/signed", т.е. атакующий уже знает содержимое как минимум одного полного блока. Следом атакующий может сформировать блок, содержащий только нули. Пара из изначально известного блока и нулевого блока обозначается как CBC-гаджет.
В ходе атаки CBC-гаджет используется для включения в состав зашифрованного текста данных атакующего. В отличие от первого варианта таки, CBC-гаджет позволяет встроить img-тег атакующего непосредственно в состав зашифрованного текста и создать единую зашифрованную MIME-часть, содержимое которой отправляется на внешний хост при разборе HTML после открытия письма пользователем. Для режима CFB, который применяется в OpenPGP, метод атаки аналогичен режиму CBC.
Некоторые факты:
- Уязвимость связана с типовыми недоработками в отдельных почтовых клиентах. Проведение первого варианта атаки без участия пользователя возможно только в Apple Mail и iOS Mail, уязвимости подвержены также PostBox, MailMate и Thunderbird, но в них для атаки требуется совершение пользователем определённых действий. Второй вариант атаки с PGP эффективен в Outlook 2007 с GPG4Win, Thunderbird с Enigmail, Apple Mail c GPGTools, Roundcube и ещё в 6 менее известных клиентах. Второй вариант атаки с S/MIME охватывает почти все протестированные клиенты, за исключением Mutt и Claws Mail;- Для успешной атаки требуется контроль за трафиком жертвы (MITM).
- Реализации OpenPGP с MDC (GnuPG) проблеме не подвержены, если почтовый клиент учитывает код проверки MDC. В S/MIME (RFC 5751) поддержка аутентифицированного шифрования не предоставляется, что требует внесения изменений в спецификацию S/MIME для устранения уязвимости. В OpenPGP (RFC 4880) спецификация предоставляет возможность аутентифицированного шифрования (MDC), которое позволяет выявить подмену CFB-блоков (поддержка MDC реализована в GnuPG в 2001 году, но при выводе через pipe для определения подмены требуется анализ кода возврата, что многие почтовые клиенты не делают).URL: https://efail.de/
Новость: https://www.opennet.me/opennews/art.shtml?num=48597
Ублюдку, который придумал слать html в письмах, надо вбить количество в ж.
Как и разработчикам почтовых клиентов, которые включают html по умолчанию.
+1. В письмах должен быть только текст, вложения и ссылки. Остальное всё ненужно и ведёт к проблемам с безопасностью.
Ну да. Чтобы ни таблицу не вставить, ни картинку, ни вменяемо оформленный текст.Вот чего там НЕ должно быть - это возможности что-то ремотно дотягивать. И даже не из соображений безопасности, а потому что письмо должно ровно также отображаться через десять лет как и в момент получения.
>Вот чего там НЕ должно быть - это возможности что-то ремотно дотягиватьВ той же птичке галочка по умолчанию отключена, для возможности запросов в Инет. Другое дело насколько точно они ей следуют.
Если есть галочка это заканчивается только тем, что пока её не нажмёшь - ни черта не понятно в письме. Сам формат не должен подобное позволять.
Не знаю, мне обычно все понятно, ибо ссылки на аттач работают, стили и отступы работают.
Если ссылка внешняя - тот кто послал ССЗБ.
> - ни черта не понятно в письме. Сам формат не должен
> подобное позволять.Ну и в качестве бонуса можно разрешать в конкретном письме или из доверенных источников.
Кто это делает в шифрованном письме от нипоймикого - ССЗБ.
Хорошо подумав понял, что был не прав по поводу второй уязвимости.
Фиг с ним с img, можно же подсунуть div с невидимостью (исходного сообщения) и свое в догонку.
А это уже реальная компрометация алгоритма.
Но к HTML это опять же отношения не имеет, можно сделать на любой разметке - оригинал белым по белому свое черным.
Markdown было бы достаточно.
AsciiDoc хватит всем!
> AsciiDoc хватит всем!Стабильного кнутовского ТеХ-а -- всем. В печёнки. Ибо не.
В принципе да, если тащить инлайновые картинки в виде multipart. Лично я бы предпочёл что-то более жёстко задающее оформление и multipart не требующее (например, подмножество PDF), но тут есть где копья ломать.
Ой, только не PDF. PostScript - это ж хоть и специфичный, но полноценный, Тьюринг-полный язык программирования.
Даёшь майнеры в письмах!
pdf и ps - разные вещи, в этом плане можно не беспокоиться
Инлайновые картинки кстати очень хорошая вещь. В вебе не используются по простой причине - тогда не работает кеширование. Но для писем же это не помеха.
> Чтобы ни таблицу не вставить, ни картинку, ни вменяемо оформленный текст.Для кучеряво оформленных документов есть специальная фича - вложения.
> Ну да. Чтобы ни таблицу не вставить, ни картинку, ни вменяемо оформленный текст.PDF в аттаче отправляйте. :)
А ведь это ПРАВДА!
Для пущей безопасности я бы еще из списка http-ссылки поудалял.
И делов-то - убедить тупых юзверей не пользоваться всякой фигней.
> И делов-то - убедить тупых юзверей не пользоваться всякой фигней.Вот это как раз дело совершенно невозможное. Они непрошибаемы (разве что ломом в висок).
> А ведь это ПРАВДА!
> Для пущей безопасности я бы еще из списка http-ссылки поудалял.
> И делов-то - убедить тупых юзверей не пользоваться всякой фигней.Ссылки то как раз дело хорошее. При нажатии главное чтоб диалог подтвержения был для открытия в браузере.
> Ублюдку, который придумал слать html в письмах, надо вбить количество в ж.
> Как и разработчикам почтовых клиентов, которые включают html по умолчанию.Полностью согласен! Вероятно идея HTML в электронной почте является самой разрушительной за всю историю ИТ. Глобальные убытки не поддаются измерению. Только маркетологи и спамеры балдеют.
И что в ней такого разрушительного и убыточного на фоне тех же аттачей?
> И что в ней такого разрушительного и убыточного на фоне тех же аттачей?Аттач еще открыть надо. А HTML - все делает сам. Начиная от выполнения хакерского activeX в древнем аутлук экспрессе в эпоху win9x. Дальше этот почетный тренд продолжился.
Я больше скажу: yблюдкy который вообще придумал EML надо большой и длинный вставить в задницу и заставить писать парсер для этого самого eml.
Ты даже не представляешь, как удобно брать мышкой выделенный текст из ворда и перетягивать в окно гмейла - он весь с форматированием остается, все красиво и удобно.
открытки рассылаешь что ли?
Обычные ИПшные вещи - например, кусок документа скопировать и выслать.
И нафига при этом вместе с текстом тащить в письмо отступы, интервалы, кегли и прочие архитектурные излишества?
Ну бывает хочется коментарии италиком, литералы одним цветом, ключевые слова другим...
Или например выделить главную мысль, вставить табличку и т.п. и т.д.
А вот, не работающая подгрузка логотипов с сайта компании это как раз то, что я не хочу видеть и мне это не показывают. :)
> Второй вариант атаки с S/MIME охватывает почти все
> протестированные клиенты, за исключением Mutt и Claws Mail;:)
>> Второй вариант атаки с S/MIME охватывает почти все
>> протестированные клиенты, за исключением Mutt и Claws Mail;
> :)Я вот, кстати, даже удивился: в кои веки Claws, который мне Опеннет из соображений политкорректности не даёт назвать предметом домашнего обихода с дырками, не оказался уязвим.
Наверное, не доделано просто, не успели присоединиться ))
Claws как был лучшим из гуевых, так и остался, лол.Кстати, Sylpheed подвержен уязвимости или нет?
Сделать MITM и пихнуть img тег!DKIM? О_о - не не слышал:)
>Сделать MITM и пихнуть img тег!
>DKIM? О_о - не не слышал:)То что DKIM подписывает исключительно заголовки (и то не все, обычно: h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To;) не слышал?
DKIM может подписать всё, что ему скажешь, в том числе и тело сообщения. Разумеется, это только в том случае, если DKIM формирует твой MUA или MTA, а не какой-нибудь google, msn, mail.ru итп.
Тут нужно отметить одно, МИТМ происходит на стороне получателя, и если отправитель подписал DKIM-мом, собственно получатель обязан по современным меркам проверить подпись, в таком случае внедрить тег и провести атаку - не получится, но тут есть НО (большое).Если мы говорим, МИТМ на стороне получателя, то подразумеваем, что атакующий котроллирует весь трафик (теоретически), так вот ниже опишу юзкейсы.
1) Атакующий тупо вырезает из заголовком подпись, сработает атака?
ДА - минус DKIM-а в том, что получатель понятия не имеет о том, что, должно ли быть подписано сообщение или нет (Если только не описано какими-либо другими правилами, к примеру DMARC). Вырезав подпись - теряем DKIM селектор, и не знаем куда за днс записью обратиться, чтобы взять ключ.
2) Атакующий не вырезает, а подменяет подпись на свою, чтобы не вызывать подозрений, и тем самым подделывает ключ в ответе от днс сервера.
Учитывая, то, что получатель идёт по селектору за ключём через днс запрос, то атакующий легко подменяет и ключ (публичный ключь) только в том случае, если днс ответы сами не подписаны механизмом к примеру DNS-SEC.
Вывод: механизм DKIM - полная лажа. Даже в связке DMARC+DKIM (DMARC dkim=s, письма с этого домена обязательно должны быть подписаны), но без DNS-SEC - полная лажа. Ситуацию с TLS(STARTTLS) не рассматриваю, потому-что изначально оговорено, что атакующий контроллирует трафик, даже TLS.
> То что DKIM подписывает исключительно заголовки (и то не все, обычно: h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To;)
> не слышал?нее, не читал!!!
>DKIM? О_о - не не слышал:)И при чем тут это?
Письмо отправляет атакующий от себя. Зачем ему этот Ваш DKIM? Он не пытается выдать себя за адресата. Он пишет письмо содержащее инструкции почтовому клиенту расшифровать то что он просит и отправить туда куда он просит. Если в клиенте настроено расшифровывать и отправлять на автомате, то - вуаля.
Расшифровать может как и клиент (получатель) так и его pgp шлюз, и тоже самое с DKIM-мом, как сам клиент проверяет DKIM, так же и его шлюз (почтовый). Тут главное выделять где именно происходит МИТМ. Приведу примеры:
Пояснения по сокращениям.
R - получатель
S - отправительSMTP_R - SMTP сервер получателя
SMTP_S - SMTP сервер отправителяВот обычная схема
[R] <-- [SMTP_R] <--INTERNET-- [SMTP_S] <-- [S]Отсюда видно, что MiTM (теоретически) можно произвести в трёх местах. В нашем случае (перехват расшифрованного письма) MiTM должен быть между [R] <-- [SMTP_R], потомучто именно либо в конечной точке [R] происходит расшифровка, либо на [SMTP_R] в случае корпоративного PGP шлюза, и схема примет вид:
[R] <--[MiTM]--- [SMTP_R] <--INTERNET-- [SMTP_S] <-- [S]Беспомощность DKIM-а описал выше.
Меня реально в этой уязвимости удивляет почему шифрование PGP и S/MIME используется без предварительного крипто подписывания сообщения? Ведь в этом случае сторонние вставки в текст становятся невозможными.
Это или от безалаберности или "By design", а то чет в последнее время палятся слишком уж очевидные
уязвимости=)))
Криптоподпись подтверждает отправителя, это не всем нужно и не всегда.
Шифрование с использованием открытого публичного ключа как бы уже подтверждает отправителя.
Можно подробностей?
> Можно подробностей?Можно. Ключ для расшифровки вы как будете выбирать на клиенте?
для -- ДЕшифровки я попробовал бы свой ключ (а не ключ отправителя.. которого, секундочку, у меня даже нет!).однако кто отправил (и не подменили ли письмо при отправке?, и не переслали ли занова вообще полностью всё письмо?) -- это ни как не прояснит
ты ошибся, брат. Бывает
Да, мне тоже удивительно, почему в сообщении с шифрованием, к тому же использующим PKI, нет подписи целостности контента. То ли это сознательно оставленная дыра, то ли одно из двух.
>Меня реально в этой уязвимости удивляет почему шифрование PGP и S/MIME используется без предварительного крипто подписывания сообщения?В данном случае это не важно. Ибо письмо посылает атакующий. Просто вставляет ту часть, которую хочет, чтобы расшифровал атакуемый. Городить же на клиенте правила, если письмо от Боба то расшифровывать ключом - Б, а если от Алисы - А, этот функционал (создание правил) не каждая домохозяйка осилит. А кто осилит, тому автоматическая расшифровка не нужна.
Опять же - mixed content разрешен почему-то. Чётких boundary сделать для криптоконтента не потрудились.
Я этим счастьем как-то сразу решил не пользоваться, для крипты есть криптованные аттачменты.
Ты фигню несёшь. Кого атакующий, посылающий письмо, атаковать будет? Себя? Ведь он максимум сможет получить сообщение, которое отправил.Тут проблема в том, что кто-то из толпы может модифицировать чужие сообщения.
> предварительногоЭто что подпись для исходного письма? лол
> невозможными
Возможным, так как подписывается не всё письмо, а только часть, выделенная разделителями. Тэг можно поставить над этим разделителем и зашифрованная часть по прежнему будет считаться проверенной. Ну и можно просто вырезать подпись из письма.
Всегда говорил, что за HTML в почте надо вешать на первом фонаре.
>Исследователи раскрыли (PDF) детали уязвимости в системах шифрования электронной почты, не дожидаясь намеченного времени публикации.лол
Эх, как не терпелось-то, а! Ведь и название придумали, и сайт запилили на красивом домене (идеально было бы efail.io, ну да ладно). Ну и что, что "предупреждение о критичности оказались слишком преувеличенными". Сайт! Логотип! Название!
"Видные британские дизайнеры, верстальщики и один маркетолог объявили о нахождении уязвимости"
то есть я, злоумышленник, могу послать письмо, включить в него шифрованный контент, получить часть письма неким параметром в обращении хттп-гетом за какой-то картинкой?
Если у получателя стоит галочка отправлять геты на сторону. Если не стоит, то нет.
Печально то, что Thunderbird оказался уязвим. Печально, но не удивительно, если сами разработчики Тундры давно уже критически недоукомплектованы и ни на что кроме как латания дыр вызванных вырезанием старого кода из Firefox у них времени не хвататет.
на офсайте написано free, easy, great features и всё совпадает. rare cases нарушения вашей приватности в формулу не входит.
>Печально то, что Thunderbird оказался уязвим.Если ССЗБ снимет галочку - получать контент из интернета для всех писем, сайтов и отправителей без разбору.
Т.е. поставит.
гг если дырка в обращении к внешним ресурсам через html, то надо запретить html. Господа предлагающие это - конкретные идиоты.