Mailsploit позволяет атаковать множество почтовых клиентов
Немецкий исследователь безопасности Sabri Haddouche обнаружил множество уязвимостей, которые он в совокупности именует Mailsploit, и которые позволяют злоумышленнику обманывать адреса электронной почты и в некоторых случаях запускать вредоносный код на компьютере пользователя.
Хотя часть выполнения кода Mailsploit вызывает беспокойство, реальной проблемой является атака электронной почты, которая обходит все современные механизмы защиты от спуфинга, такие как DMARC (DKIM / SPF) или различные спам-фильтры.
Это позволяет злоумышленникам отправлять электронные письма с поддельными идентификаторами, которые как пользователям, так и серверам электронной почты с трудом обнаруживают в качестве подделок. Это, в свою очередь, делает попытки фишинг-атаки и загруженные вредоносными почтовыми сообщениями гораздо более сложными для обнаружения
Как работает Mailsploit
Уязвимость Mailsploit объясняется тем, как почтовые серверы интерпретируют адреса электронной почты, закодированные с помощью RFC-1342. Это стандарт, принятый в 1992 году, в котором описывается способ кодирования символов, отличных от ASCII, внутри заголовков электронной почты.
По правилу все содержимое, содержащееся в заголовке электронной почты, должно быть символом ASCII. Авторы стандартов электронной почты приняли RFC-1342, чтобы автоматически преобразовывать символы, отличные от ASCII, в стандартные символы ASCII и избегать ошибок, когда электронные письма с линией темы, не содержащей ASCII, или адресом электронной почты, переданным через сервер.
Хаддуш обнаружил, что большое количество почтовых клиентов будет принимать кодированную строку RFC-1342, декодировать ее в не-ASCII-состоянии, но впоследствии не будет дезинфицировать ее для проверки наличия вредоносного кода.
Кроме того, если в строке RFC-1342 с расшифрованной электронной почтой содержались нулевые или два или более адреса электронной почты, клиент электронной почты считывал бы только адрес электронной почты до нулевого байта или первый действительный адрес электронной почты, с которым он столкнулся.
Это означает, что злоумышленник может создать действительный адрес электронной почты, имя которого на самом деле является строкой, кодированной RFC-1342:
... который декодируется внутри почтового клиента:
Уязвимые почтовые клиенты, анализирующие эти строки, будут читать только первый электронный адрес ([email protected]), игнорируя настоящий домен электронной почты (@ mailsploit.com). Причина, как объяснялось выше, является нулевым байтом (\ 0) или потому, что [email protected] является первым действительным адресом электронной почты, с которым сталкивается клиент, и игнорирует остальную часть строки.
Haddouche обнаружил недостатки Mailsploit в начале этого года и говорит, что он протестировал несколько почтовых клиентов и веб-сервисов, чтобы увидеть, какие из них уязвимы.
https://www.bleepingcomputer.com/news/security/mailsploit-lets-attackers-send-spoofed-emails-on-over-33-email-clients/
https://xakep.ru/2017/12/06/mailsploit/
Хотя часть выполнения кода Mailsploit вызывает беспокойство, реальной проблемой является атака электронной почты, которая обходит все современные механизмы защиты от спуфинга, такие как DMARC (DKIM / SPF) или различные спам-фильтры.
Это позволяет злоумышленникам отправлять электронные письма с поддельными идентификаторами, которые как пользователям, так и серверам электронной почты с трудом обнаруживают в качестве подделок. Это, в свою очередь, делает попытки фишинг-атаки и загруженные вредоносными почтовыми сообщениями гораздо более сложными для обнаружения
Как работает Mailsploit
Уязвимость Mailsploit объясняется тем, как почтовые серверы интерпретируют адреса электронной почты, закодированные с помощью RFC-1342. Это стандарт, принятый в 1992 году, в котором описывается способ кодирования символов, отличных от ASCII, внутри заголовков электронной почты.
По правилу все содержимое, содержащееся в заголовке электронной почты, должно быть символом ASCII. Авторы стандартов электронной почты приняли RFC-1342, чтобы автоматически преобразовывать символы, отличные от ASCII, в стандартные символы ASCII и избегать ошибок, когда электронные письма с линией темы, не содержащей ASCII, или адресом электронной почты, переданным через сервер.
Хаддуш обнаружил, что большое количество почтовых клиентов будет принимать кодированную строку RFC-1342, декодировать ее в не-ASCII-состоянии, но впоследствии не будет дезинфицировать ее для проверки наличия вредоносного кода.
Кроме того, если в строке RFC-1342 с расшифрованной электронной почтой содержались нулевые или два или более адреса электронной почты, клиент электронной почты считывал бы только адрес электронной почты до нулевого байта или первый действительный адрес электронной почты, с которым он столкнулся.
Это означает, что злоумышленник может создать действительный адрес электронной почты, имя которого на самом деле является строкой, кодированной RFC-1342:
От: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com
... который декодируется внутри почтового клиента:
От: [email protected] \ 0 ([email protected]) @ mailsploit.com
Уязвимые почтовые клиенты, анализирующие эти строки, будут читать только первый электронный адрес ([email protected]), игнорируя настоящий домен электронной почты (@ mailsploit.com). Причина, как объяснялось выше, является нулевым байтом (\ 0) или потому, что [email protected] является первым действительным адресом электронной почты, с которым сталкивается клиент, и игнорирует остальную часть строки.
Haddouche обнаружил недостатки Mailsploit в начале этого года и говорит, что он протестировал несколько почтовых клиентов и веб-сервисов, чтобы увидеть, какие из них уязвимы.
https://www.bleepingcomputer.com/news/security/mailsploit-lets-attackers-send-spoofed-emails-on-over-33-email-clients/
https://xakep.ru/2017/12/06/mailsploit/
Мы ищем точки опоры не с целью перевернуть мир, но чтобы не позволить миру опрокинуть нас.
Тэги темы:
Войдите или Зарегистрируйтесь чтобы комментировать.