//
вы читаете...
Информационная безопасность, Протоколы, Системное администрирование

Блокирование передачи файлов в Mail.Ru агенте

Внимание

Читайте пролог под катом, так как майл.ру агент изменил протокол.

Эта статья является частью цикла «Ограничение передачи файлов в интернет». В цикл входят статьи:

В заметке «Организация использования Mail.Ru агента в корпоративной сети» описан формат сообщения Mail.Ru агента, и даны рекомендации по блокированию передачи файлов.

Хочется заметить, что многие считают, что файлы Mail.Ru агента передаются по каким-то особым портам, отличным от портов для передачи текстовых сообщений. Однако это в корне неверно. Функции передачи файлов и функции передачи текстовых сообщений реализованы на порту 2041.

В этой статье мы подробно рассмотрим процесс приема и передачи файлов с помощью Mail.Ru агента, а также познакомимся с основами реализации его протокола.

Пролог, связанный со сменой протокола

С помощью сниффера выяснилось, что заголовок пакета изменился с 0xEFBEADDDE на 0x17030100. Тело пакета стало полностью зашифровано, однако выяснилось, что есть незашифрованные последовательности, которые обозначают, судя по всему, тип сообщения.

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

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


iptables -A OUTPUT -m string --algo bm --hex-string "|17 03 01 00|" -j DROP

И, вуаля, получился неожиданный, но очень интересный результат: мой клиент не смог соединиться с сервером по протоколу новой версии, но соединился по протоколу старой версии! (никогда я так не радовался словам «обратная совместимость» =) ).

Таким образом, в настоящее время для применения данной статьи достаточно обрубить новую версию протокола, поставив перед всеми правилами приведенное выше. Удачи!

Этап 1. Анализ потребностей

Наша задача состоит в том, чтобы предоставить сотрудникам возможность пользоваться Mail.Ru агентом для переписки, но исключить возможность приема/передачи файлов, так как обе эти возможности создают угрозы безопасности внутренней сети.

Этап 2. Расследование

Определимся с теоретической базой. Описание протокола обмена сообщениями доступно на странице http://agent.mail.ru/ru/developers/protocol.html. Там же доступен и заголовочный файл, описывающий прототипы пакетов.

Попробуем передать файл testfile.zip с помощью Mail.Ru агента.

Рисунок 1. Дамп пакета, перехваченного при попытке передачи файла

Разберемся со структурой пакета Mail.Ru агента (при написании статьи выяснилось, что Mail.Ru агент в этом же пакете передает адреса всех сетевых интерфейсов, они замазаны красным цветом).

Рисунок 2. Структура пакета Mail.Ru агента

Выдержка из официального описания протокола (орфография и пунктуация сохранены).

MMP бинарный протокол. Все числовые данные передаются как четырехбайтные целые НЕ в сетевом формате, т.е. первым идет старший байт, последним младший. Четырехбайтовые беззнаковые целые обозначаются UL.

Текстовые данные передаются с префексированной длиной, т.е. сначала UL, а потом строка (в кодировке windows-1251) длины UL без завершающего нуля. Обозначение в дальнейшем – LPS.

Каждая команда или ответ на нее начинаются с заголовка. Поля, указываемые в заголовке:

  • волшебный ключ, указывающий на то, что это действительно пакет MMP – версия MMP, поддерживаемая отправителем пакета
  • номер отправляемой команды в текущем соединении. Ответ на команду должен иметь тот же номер, что и сама команда.
  • тип пакета, номер команды и/или ответа
  • длинна данных пакета (без учета заголовка). При обработке посылаемых сервером данных длина пакета должна иметь приоритет перед списком его параметров, т.к. в следующих версиях протокола могут появляться новые параметры и все они будут дописываться в конец пакета.
  • порт и ip (в inet_aton() формате) с которых установлено соединение.

Разберем заголовок пакета.

По адресу 0030:0006 размещается значение DWORD, обозначающее магический ключ.

По адресу 0030:000А размещается значение DWORD, обозначающее версию протокола.

По адресу 0030:000E размещается значение DWORD, содержащее sequence-номер сообщения.

По адресу 0040:0002 размещается значение DWORD, указывающее на тип сообщения.

По адресу 0040:0006 размещается значение DWORD, содержащее длину сообщения после заголовка пакета.

По адресу 0040:000A размещается значение DWORD, содержащее ip-адрес отправителя.

По адресу 0040:000E размещается значение DWORD, содержащее номер порта отправителя.

Следующие 16 байт являются зарезервированными, и на них заголовок пакета Mail.Ru агента заканчивается.

Анализ официального описания протокола и заголовочного файла показывает, что при отправке текстового сообщения пакет обозначается MRIM_CS_MESSAGE, и по адресу 0040:0002 размещается значение DWORD 0x08100000 (0x1008 в сетевом формате). При приеме сообщения там будет содержаться значение 0x09100000 (0x1009).

В документации описывается тип пакета MRIM_CS_FILE_TRANSFER, который используется при передаче файла. Однако значение поля «тип сообщения» указывается в заголовочном файле, а в нем, к сожалению, прототип этого пакета не помещен. Наверное, забыли. Но снифферы никто не отменял. Посмотрев в дамп, приведенный на рисунке 1, можно заметить, что тип сообщения, инициирущего передачу файлов собеседнику – 0x00001026.

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

Рисунок 3. Дамп пакета, перехваченного при уведомлении о приеме файла

Этап 3. Анализ полученной информации

  1. Пакет Mail.Ru агента характеризуется «магическим ключом», расположенным в пакете по адресу 0030:0006 и имеющим постоянное значение типа DWORD.
  2. При попытке отправить или принять файл поле типа сообщения в пакете устанавливается в 0x00001026.
  3. Поле типа сообщения в пакете всегда находится по одному и тому же адресу 0040:0002.

Составляем правила.

#       Создаем цепочку для пакетов MRA
iptables -N MRA_Packets
# Проверяем пакет mail агента
# если передается файл, то сначала записываем факт в лог
iptables -A MRA_Packets -m u32 --u32 "52=0x26100000" -j LOG --log-prefix "MRA File Transferring: " --log-level 7
# а затем отбрасываем его
iptables -A MRA_Packets -m u32 --u32 "52=0x26100000" -j DROP
#     Проверка на выходе
iptables -A OUTPUT -m u32 --u32 "40=0xEFBEADDE" -j MRA_Packets
#     Проверка на входе
iptables -A INPUT -m u32 --u32 "40=0xEFBEADDE" -j MRA_Packets
Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: