Сетевая разведка сервиса электронной почты

Сетевая разведка сервиса электронной почты

Разведка... Что у вас возникает в голове при этом слове ? А при термине сетевая разведка ? Пока вы в раздумиях задам еще пару вопросов. А сервис электронной почты важен для вас и/или вашей компании ? Понимаете ли вы что понятия конфиденциальность целостность и доступность относятся не только к защищаемой вами информации, но и к компонентам вашей сети, сервисам ? Наиболее полное исследование в области сетевой разведки сервисов, в данном случае электронной почты, объединяющее в себе передовые международные методики разведки и авторские идеи, позволяющее вам самим дать ответы на заданные выше вопросы представлено на конкурс Securitylab.

Автор: Павел П. ака UkR-XblP (UkR security team) ust.info@gmail.com

Введение:

Довольно часто человек, так или иначе вовлеченный в направление информационной безопасности, сталкивался с терминами, изначально применяемыми в таких областях как армия, различные службы обеспечения безопасности граждан (к примеру, МЧС, Служба Спасения, Скорая помощь). Вы наверняка тут же вспомнили такие простые слова как атака, нападение, защита, разведка. Даже появлением западного аналога термину межсетевой экран мы обязаны армии - это всем известный firewall, в дословном переводе "огненная_стена" - огнеупорная стена, ограждение.

Но почему же специалисты в области информационной безопасности (далее ИБ) зачастую берут из наработанного годами опыта, методологий, уставов (заявления командиров о том, что "каждая строчка в Уставе написана кровью солдат" имеют под собой достаточно весомое основание) только названия и термины? В данной статье я попытаюсь рассмотреть и применить методы и способы военной разведки в Вооруженных Силах к ИБ, а именно такому аспекту как проведение сетевой разведки сервиса электронной почты, в которой заинтересованы специалисты, проводящие тестирование на проникновение (penetration testing), тестирование защищенности (security testing), а также аналитики ИБ и администраторы ИБ, для которых необходимо понимание методов и способов, которыми могут воспользоваться злоумышленники для сбора информации о сервисе электронной почты и эксплуатации существующих уязвимостей.

Итак, дадим определение понятию военная разведка (далее ВР), необходимое нам для понимания его проецирование на сетевую разведку (далее СР.).

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

На основе этого определения постараемся дать определение СР.

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

Современная ВР в зависимости от масштаба, целей деятельности и характера, поставленных для выполнения задач делится на:

  • тактическую (оперативную);
  • стратегическую.

Тактическая разведка обеспечивает действия атакующих (к ним будем относить, как и злоумышленников, так и специалистов, проводящих тестирование) в соприкосновении с противником (целевой системой электронной почты). Она выявляет данные о возможностях противника (его техническом, программном оснащении), уязвимости противника (уязвимостей почтовых серверов, сервисов и почтовых клиентов) и районе действий (границы сегментов сети, используемые каналы связи (тип, пропускная способность), государственная (географическая и коммерческая принадлежность сети и/или сервера)), что облегчает и определяет принятие атакующими оптимальных решений по планированию и проведению атаки на информационные системы (далее ИС).
В ВР все эти сведения добываются опросом местных жителей, допросом пленных и перебежчиков, перехватом информации, передаваемой радиоэлектронными средствами, изучением захваченных у противника документов, техники и вооружения.

Из каких частей складывает любой разведцикл?
В своем классическом понимании разведцикл принято делить на пять составных частей:

  1. Планирование и целеуказание;
  2. Сбор - добывание данных;
  3. Обработка разведывательных данных - превращение их в разведывательную информацию;
  4. Анализ и синтез разведывательной информации;
  5. Распространение.

А какие этапы для осуществления несанкционированного взлома используют злоумышленники?

  1. Выбор исследуемой сети/сервера/информационного пространства;
  2. Сканирование, тестирование, сбор информации о цели.
  3. Обработка данных, выбор уязвимой точки для проникновения.
  4. Эксплуатация уязвимости, проникновение в систему.
  5. Далее действия хакера зависят от задачи, поставленной им, будь то изменения информации, кража, повышение полномочий и удержание системы.

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

  1. Мероприятия сетевой разведки;
  2. Проведение атаки на целевую систему;
  3. Дальнейшие действия хакера в системе.

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

Определение границ разведки проходит в несколько этапов.

Возможные пути получения данных:

  • получение информации от whois-серверов;
  • просмотр информации DNS серверов исследуемой сети для выявления записей, определяющих маршруты электронной почты (MX записи);
  • информация об электронной почте, представленные на сайте исследуемой компании. К ней относятся адреса электронной почты для связи, опубликованные вакансии для системных администраторов и администраторов электронной почты, в которых зачастую есть информация о типах используемых почтовых серверов;
  • информация об электронной почте (адресах) и вакансиях (см. выше) сохранившиеся в поисковых системах (google.com, yandex.ru), так и в базах компаний, запоминающих состояния веб-ресурсов на определенный срок (web.archive.org).

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

  • сканирование портов (сервисов) на выявленных внешних серверах. Проводится с целью определить:
  • доступность сервиса из различных подсетей, расположенных по всему миру. Ибо если с одного адреса сервис может быть недоступен (довольно часто блокируют соединения из азиатских сетей как основной источник спама);
  • выявление почтовых сервисов на нестандартных портах;
  • получение и анализ информации, выдаваемой почтовыми сервисами при соединении. Banner grabbing - так этот метод принято называть среди специалистов по сетевой разведке.
  • активная проверка сервиса (smtp, pop3, pop3pw, imap) для определения типа и версии, допуская возможность что администратор системы изменил информацию, выдаваемую сервисами, или сервис не выводит информацию о своем типе и версии.
  • отправка писем на несуществующие почтовые адреса для получения NDR (non delivery report) и информации о пути прохождения письма.

При этом, возможно определить следующее:

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

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

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

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

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

Все что вы прочли выше, являлось теорией. Ниже будет представлен практический пример разведки сервиса электронной почты компании НИП Информзащита (адрес сайта: www.infosec.ru). Я справедливо полагаю, что компания, являющаяся одним из крупнейших поставщиков услуг по информационной безопасности, а также разработавшая и преподающая авторский курс "Безопасность электронной почты", будет наилучшим примером применением методов сетевой разведки.

  1. Получение информации от WHOIS-сервера RIPN.
    % By submitting a query to RIPN's Whois Service
    % you agree to abide by the following terms of use:
    % http://www.ripn.net/about/servpol.html#3.2 (in Russian)
    % http://www.ripn.net/about/en/servpol.html#3.2 (in English).

    domain: INFOSEC.RU
    type: CORPORATE
    nserver: a.ns.infosec.ru. 194.226.94.219
    nserver: ns4.nic.ru.
    state: REGISTERED, DELEGATED
    org: Joint Stock Company NIP "InformZaschita"
    phone: +7 096 9373385
    phone: +7 095 2193188
    phone: +7 095 2894232
    fax-no: +7 096 9373385
    fax-no: +7 095 2193188
    fax-no: +7 095 2894232
    e-mail: noc@infosec.ru
    e-mail: van@df.ru
    registrar: RUCENTER-REG-RIPN
    created: 1996.11.03
    paid-till: 2004.12.01
    source: RIPN

    Интересующая нас информация:
    NS-сервера
    контактная информация

  2. Получение информации с NS серверов компании.

    Reply from a.ns.infosec.ru : 233 bytes recieved
    Direct authoritative answer: recursion desired; recursion available; result: succesful.
    Contains 1 question entries, 8 answer entries, 0 nameserver records and 1 additional records.

    > Questions:
    infosec.ru type: ANY (all records) class: IN (Internet)
    > Answers:
    infosec.ru 10800 A 217.106.229.76
    infosec.ru 10800 SOA convert.infosec.ru
    email: hostmaster.infosec.ru
    serial: 2004400701
    refresh: 3600
    retry: 3600
    expire 604800
    minimum 3600
    infosec.ru 10800 NS ns4.nic.ru
    infosec.ru 10800 NS a.ns.infosec.ru
    infosec.ru 10800 MX 10 a.mx.infosec.ru
    infosec.ru 10800 MX 20 b.mx.infosec.ru
    infosec.ru 10800 MX 30 c.mx.infosec.ru
    infosec.ru 10800 MX 40 d.mx.infosec.ru
    > Additional information:
    a.ns.infosec.ru 10800 A 194.226.94.219

    Выявили:
    Адреса почтовых серверов компании и их приоритет.
    Контактная информация.

  3. Информация о сервисе электронной почты на сайте www.infosec.ru:

    Контактная информация:

  4. Информация о сервисе из поисковых систем google и yandex:

    Контактная информация:

  5. Сканирование серверов a.mx.infosec.ru, b.mx.infosec.ru, c.mx.infosec.ru, d.mx.infosec.ru.

    15.10.2004 14:11:03 Соединение: -> a.mx.infosec.ru:25
    Статус: соединение установлено
    Баннер сервиса:
    220 convert.infosec.ru ESMTP Postfix

    15.10.2004 14:12:57 Соединение: -> b.mx.infosec.ru:25
    Статус: соединение установлено
    Баннер сервиса:
    220 relay.infosec.ru ESMTP

    15.10.2004 14:11:20 Соединение: -> c.mx.infosec.ru:25
    Статус: соединение установлено
    Баннер сервиса:
    220 convert.infosec.ru ESMTP Postfix

    15.10.2004 14:13:05 Соединение: -> d.mx.infosec.ru:25
    Статус: соединение установлено
    Баннер сервиса:
    220 relay.infosec.ru ESMTP

    В результате мы получили адреса почтовых серверов, точнее их имена. Мы видим что записи a.mx.infosec.ru и с.mx.infosec.ru, b.mx.infosec.ru и d.mx.infosec.ru ссылаются на 2 различных почтовых сервера соответственно. По-видимому данные меры направлены на повышение уровня отказоустойчивости сервиса электронной почты.

    Также уже может предположить, что в качестве MTA (Mail Transfer Agent) по-крайней мере на одном из двух почтовых сервере используется Postfix.

    Баннер другого сервера никакой информации о себе нам не раскрыл.

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

    helo - Эта команда используется что бы идентифицировать SMTP-отправителя на принимающем сервере. Применена без параметра;
    helo aaa - Применена с ошибочным параметром;
    vrfy - Эта команда просит подтвердить получателя, что он идентифицировал пользователя по аргументу. Для этого должны быть возвращены имя (полное имя) пользователя или почтовый адрес. Применена без параметра;
    vrfy aaa - Применена с ошибочным параметром;
    mail - Эта команда используется что бы отправить почту по одному или более адресатам. Применена без параметров.
    data - Получатель получает данные о дате отправке почты. Но так как мы ничего и не посылали, ждем сообщение об ошибке.
    finger - несуществующая команда. У каждого почтового сервиса своя реакция на несуществующие команды.
    rset - Эта команда определяет, что текущая работа с почтой должна быть прервана.
    quit - Выходим.

    Ответов каждого из почтовых серверов на эти команды хватит для идентификации любого почтового сервера. Проверим это на практике:

    ----------------------------------------------------------------
    220 convert.infosec.ru ESMTP Postfix
    helo
    501 Syntax: HELO hostname
    helo aaa
    250 mail.picturetrail.com
    vrfy
    501 Syntax: VRFY address
    vrfy aaa
    450 <aaa>: User unknown in local recipient table
    mail
    501 Syntax: MAIL FROM: <address>
    data
    503 Error: need RCPT command
    finger
    502 Error: command not implemented
    rset
    250 Ok
    quit
    221 Bye
    ----------------------------------------------------------------

    и для второго сервера:

    ----------------------------------------------------------------
    220 relay.infosec.ru ESMTP
    helo
    250 relay.infosec.ru is pleased to meet you
    helo aaa
    250 relay.infosec.ru is pleased to meet you
    vrfy
    252 Send some mail, I'll try my best
    vrfy aaa
    252 Send some mail, I'll try my best
    mail
    250 ok
    data
    503 RCPT first (#5.5.1)
    finger
    502 Unimplemented (#5.5.1)
    rset
    250 flushed
    quoit
    502 Unimplemented (#5.5.1)
    quit
    221 relay.infosec.ru signing off...
    ----------------------------------------------------------------

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

    Внимание !!!
    a.mx.infosec.ru подозрение на ESMTP Postfix
    Внимание !!!
    b.mx.infosec.ru соответствует Qmail SMTP server

    Слепки для этих 2х серверов ниже:

    [ESMTP Postfix]
    1=Syntax: HELO hostname
    2=250
    3=Syntax: VRFY address
    4=252 aaa
    5=Syntax: MAIL FROM: <address>
    6=Error: need RCPT command
    7=Error: command not implemented
    8=250 Ok
    9=Bye

    [Qmail SMTP server]
    1=250
    2=250
    3=send some mail, i'll try my best
    4=send some mail, i'll try my best
    5=ok
    6=RCPT first
    7=unimplemented
    8=flushed
    9=221

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

    В итоге у нас уже есть достоверная информация, что в компании Информзащита в качестве почтовых серверов используются Postfix и Qmail. Подразумевая что профиль компании информационная безопасность версии этих серверов должны быть из последних. Уже на данном этапе можно попытаться эксплуатировать имеющиеся в этих почтовых серверах уязвимости, однако цель статьи не в этом. Продолжим исследование.

  7. NDR:

    Я отправил почтовые сообщения с незаполненной темой и телом письма на несуществующие адреса известных мне почтовых серверов - stopthis@convert.infosec.ru и stopthis@relay.infosec.ru.

    Сначала проанализируем содержание вернувшихся сообщений о невозможности доставки писем, вернувшиеся мне.
    ----------------------------------------------------------------
    От: MAILER-DAEMON@convert.infosec.ru
    Отправлено: 11 октября 2004 г. 14:15
    Кому: UkR security team
    Тема: Undelivered Mail Returned to Sender

    This is the Postfix program at host convert.infosec.ru.

    I'm sorry to have to inform you that the message returned
    below could not be delivered to one or more destinations.

    For further assistance, please send mail to <postmaster>

    If you do so, please include this problem report. You can delete your own text from the message returned below.

    The Postfix program

    <stopthis@convert.infosec.ru>: unknown user: "stopthis"
    ----------------------------------------------------------------

    Мы еще раз убедились что convert.infosec.ru - это Postfix. С другой стороны несколько смущает то что у компании, занимающейся ИБ, оставлены многие параметры без изменений. В других случаях это может свидетельствовать о применении обманной системы или систем-ловушек (honeypot), в последнее время развитие получили Mail honeypot системы, занимающиеся отловом адресов, с которых распространяется спам или почтовые вирусы.

    Ответ второго сервера:
    ----------------------------------------------------------------
    От: MAILER-DAEMON@relay.infosec.ru
    Отправлено: 11 октября 2004 г. 14:14
    Кому: UkR security team
    Тема: failure notice

    Hi. This is the qmail-send program at relay.infosec.ru.
    I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out.

    <stopthis@relay.infosec.ru>:
    Sorry, no mailbox here by that name. (#5.1.1)
    ----------------------------------------------------------------

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

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

    Вот лишь маленький список:
    POSTFIX: MAILER-DAEMON@Undelivered Mail Returned to Sender
    QMAIL: MAILER-DAEMON@failure notice
    EXIM: Mailer-Daemon@Mail delivery failed returning message to sender
    SENDMAIL: MAILER-DAEMON@Returned mail see transcript for details

    Теперь проанализируем заголовки вернувшихся NDR:

    ----------------------------------------------------------------
    Received: from convert.infosec.ru (194.226.94.219 [194.226.94.219]) by ukrserver.ustinfo.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
    id 4VY53711; Mon, 11 Oct 2004 14:27:06 +0400
    Received: by convert.infosec.ru (Postfix)
    id 4661418086; Mon, 11 Oct 2004 14:15:12 +0400 (MSD)
    Date: Mon, 11 Oct 2004 14:15:12 +0400 (MSD)
    From: MAILER-DAEMON@convert.infosec.ru (Mail Delivery System)
    Subject: Undelivered Mail Returned to Sender
    To: research@ustinfo.ru
    MIME-Version: 1.0
    ----------------------------------------------------------------

    Полученная нами информация:

    IP адрес convert.infosec.ru 194.226.94.219.

    Значение SMTP ID TAG, которое также дает нам возможность определить версию почтового сервера. Об этом была моя статья "SMTP ID фингерпринт" участвовшая в первом конкурсе на securitylab.ru. С помощью утилиты UST.SITF (ссылка в конце статьи) определим версию почтового сервиса на основании следующей строки:
    Received: by convert.infosec.ru (Postfix) id 4661418086

    HOST: convert.infosec.ru (Postfix)
    ID: 4661418086
    SIGN: 000000100100me
    TYPE: Postfix MTA

    Результат: Соответствует ESTMP MTA POSTFIX.

    Второй сервер:
    ----------------------------------------------------------------
    Received: from relay.infosec.ru (un.infosec.ru [194.226.94.210]) by ukrserver.ustinfo.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
    id 4VY537DZ; Mon, 11 Oct 2004 14:26:34 +0400
    Received: (qmail 24420 invoked for bounce); 11 Oct 2004 10:13:41 -0000
    Date: 11 Oct 2004 10:13:41 -0000
    From: MAILER-DAEMON@relay.infosec.ru
    To: research@ustinfo.ru
    Subject: failure notice
    ----------------------------------------------------------------

    Полученная нами информация:
    Соответствие hostname relay.infosec.ru имени un.infosec.ru. При полной разведке сети это может помочь в определении топологии сети и взаимосвязи.
    IP адрес relay.infosec.ru 194.226.94.210.

    Теперь попробуем послать email не конкретно на обнаруженные почтовые сервера, а съэмулировать реальное письмо. Также отправляем на несуществующий адрес stopthis@infosec.ru

    Проанализируем вернувшийся заголовок письма:
    ----------------------------------------------------------------
    Received: from convert.infosec.ru (194.226.94.219 [194.226.94.219]) by ukrserver.ustinfo.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
    id 4VY538SP; Mon, 11 Oct 2004 18:05:59 +0400
    Received: from nt_server.infosec.ru (unknown [200.0.0.5])
    by convert.infosec.ru (Postfix) with ESMTP id DBD6C180CB
    for <research@ustinfo.ru>; Mon, 11 Oct 2004 17:54:05 +0400 (MSD)
    From: postmaster@infosec.ru
    To: research@ustinfo.ru
    Date: Mon, 11 Oct 2004 17:44:02 +0400
    MIME-Version: 1.0

    Message-ID: <xZfQmNcEH000001e6@nt_server.infosec.ru>
    Subject: Delivery Status Notification (Failure)

    Received: from spam.infosec.ru ([192.168.200.21]) by nt_server.infosec.ru with Microsoft SMTPSVC(6.0.3790.0);
    Mon, 11 Oct 2004 17:44:02 +0400
    Received: from antispam.localhost (localhost.localdomain [127.0.0.1])
    by spam.infosec.ru (Postfix) with SMTP id C90B517FC6
    for <stopthis@infosec.ru>; Mon, 11 Oct 2004 17:45:49 +0400 (MSD)
    Received: from relay.infosec.ru (unknown [192.168.200.3])
    by spam.infosec.ru (Postfix) with SMTP id 92F3817F56
    for <stopthis@infosec.ru>; Mon, 11 Oct 2004 17:45:49 +0400 (MSD)
    Received: (qmail 6617 invoked by uid 0); 11 Oct 2004 13:43:01 -0000
    Received: from ustinfo.ru (HELO )
    by 0 with SMTP; 11 Oct 2004 13:43:01 -0000
    Message-Id: <20041011134549.92F3817F56@spam.infosec.ru>
    Date: Mon, 11 Oct 2004 17:45:49 +0400 (MSD)
    From: research@ustinfo.ru
    To: undisclosed-recipients: ;
    X-Spamtest-Info: Pass through
    Return-Path: research@ustinfo.ru
    ----------------------------------------------------------------

    Полученная нами информация:
    Выявили цепочку прохождения письма, она такова

    Отправитель посылает письмо
    -> получает письмо relay.infosec.ru (Received: (qmail 6617 invoked by uid 0)). Отправляет его далее (relay на внутренние сервера).
    -> получает письмо spam.infosec.ru. По имени хоста и строке X-Spamtest-Info: Pass through можно сделать вывод что на нем фильтруется входящая почта. Можно предположить также и антивирусную проверку на данном этапе, хотя нет никаких свидетельств этому. Отправляет его далее. (опять relay на внутренний сервер).
    -> получает письмо nt_server.infosec.ru. Именно на этом сервере хранятся почтовые ящики пользователей. Сервер наконец то обнаружил что получатель не существует и возвращает письмо.
    -> получает письмо пограничный почтовый сервер convert.infosec.ru и отправляет его наконец то мне.
    -> я получил этот результат.

    Что же мы имеем в результате:

    1. Выявили что внутренняя сеть компании Информзащита находится за NAT и использует зарезервированные для внутренних сетей адреса 192.168.200.*
    2. Выявили наличие пограничника, пса-цербера. Я имею ввиду наличие промежуточного сервера на котором проводится отсеивание спама под управлением Postfix. Его внутренний IP-адрес - 192.168.200.21.
    3. Определили что внутренняя почтовая сеть построеная на решениях компании Microsoft. Так как почтовый сервер под управлением Windows (об этом нам говорит имя хоста - nt_server и принимающий сервис - Microsoft SMTPSVC(6.0.3790.0)). Можем предположить что почтовые клиенты - это Microsoft Outlook.
    4. Можем заметить что не производится анализ исходящей почты (нет никаких свидетельств этому). Этим может воспользоватся проникнувший во внутреннюю сеть злоумышленник для отправления информации и сотрудниками компании (я подразумеваю возможность утечки информации).
    5. сервер relay.infosec.ru занимается приемом почты, а convert.infosec.ru ее отправлением.
  8. NDR-Attack.

    Общепризнаное понимание этого термина таково:

    Почтовые сервера, отправляя NDR, сохраняют в теле письма исходное сообщение. Этим и пользуется спамеры. Ставя целью послать рекламные сообщения на адрес noc@infosec.ru они могут реализовать следующий алгоритм:

    Адрес noc@infosec.ru использовать в качестве адреса отправителя.
    Подсоединившись напрямую к серверу convert.infosec.ru, послать сообщение рекламного характера на несуществующий адрес *@convert.infosec.ru.
    Мы уже знаем что convert.infosec.ru сконфигурирован так, что отсылает NDR. Следовательно он вернет NDR, в теле которого будет содержаться рекламное сообщение на целевой адрес noc@infosec.ru. Есть вероятность по которой это письмо не будет заблокировано на хосте spam.infosec.ru при его прохождении. У системных администраторов почтовых систем при использовании антиспамовых систем адреса собственной почты (в нашем случае *@*infosec.ru) находятся в белом списке и не подлежат проверке.

    Альтернативный вариант - это реклама на другие сервера. То есть мы реально можем слать рекламу на адрес admin@securitylab.ru с серверов Информзащиты.
    Если мы можем рекламировать с серверов Информзащиты другие сервера - у нас есть реальная возможность компрометации сервера convert.infosec.ru. Стоит неделю так активно прорекламировать какой либо товар и сервер непременно попадет в международные blacklists спамеров (DNSBL). Все почтовые антиспамовые системы обычно не принимают письма от адресов, находящихся в этом списке. Следовательно никто из партнеров компании Информзащиты, использующие у себя антиспамовые системы, не будут принимать от нее почтовые сообщения. Для Информзащиты это может стать серьезной проблемой нарушив бизнес-процессы.

    Я лично использую этот термин (NDR-attack) в несколько другом понимании.

    Основы протокола SMTP, служащего для передачи почтовых сообщений, определены в RFC -821 и RFC-2821. Эти RFC предусматривают что для отправления почтового сообщения по нескольким адресам (в почтовых клиентах это поля СС:, BCC:) на одном сервере отправителю надо послать только 1 (одну) копию письма.

    Попробую послать письма нескольким несуществующим пользователям с сервера convert.infosec.ru на адреса *@*infosec.ru:

    MAIL FROM:<attacker@convert.infosec.ru>
    250 OK
    RCPT TO:<testlamer@convert.infosec.ru>
    250 OK
    RCPT TO:<testuser@relay.infosec.ru>
    250 OK
    RCPT TO:<testhacker@infosec.ru>
    250 OK
    DATA
    354 data;end with <CRLF>.<CRLF>
    я вас всех люблю

    <CRLF>.<CRLF>
    250 OK

    Что мы будем иметь в результате:

    Размер одного NDR сообщения 6 kb.
    Я фактически послал строку длиной 20 байт.
    Сервер послал информации объемом 6*3(число получателей)kb

    То есть даже при таком раскладе мы видим явное умножение траффика, что является одним из основных признаков DOS-атаки.

    Но внимание, как я уже упоминал выше - NDR сохраняет исходное письмо !
    Следовательно если я пошлю письмо объемом 1 mb, почтовый сервер отошлет его в количестве 3 mb. Дальнейшие расчеты зависят только от вашей фантазии. А примет ? Правильно ! Тоже 3 мб.

    я -> 1 мб -> convert.infosec.ru -> 3 мб -> relay.infosec.ru -далее NDR
    cоединяюсь отправитель: attacker
    получателей: 5
    <- 3 мб <- relay.infosec.ru

    Итого послав 1 мб данных я загрузил канал связи Информзащиты на 6 мб.

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

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

  9. Работа с пользователями:

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

    ----------------------------------------------------------------

    От: UkR security team
    Отправлено: 15 октября 2004 г. 14:19
    Кому: 'market@infosec.ru'
    Копия: 'edu@infosec.ru'
    Тема: Запрос на прайс

    Здраствуйте.

    Не могли бы вы прислать прайс-лист ваших учебных курсов по состоянию на 15.10.2004.

    И один вопрос: оказывает ли Информзащита услуги в области проведения сетевой разведки ?

    ------------------------------------
    C уважением,

    Павел П. aka UkR-XblP.
    ----------------------------------------------------------------

    И получил ответ:

    ----------------------------------------------------------------
    От: Natalya O. Ruban [rno@itsecurity.ru]
    Отправлено: 15 октября 2004 г. 15:55
    Кому: UkR security team
    Тема: RE: Запрос на прайс

    Добрый день Павел П.!

    Высылаю Вам информацию по курсам и ценам на 2004 и 2005 год.

    По поводу второго вопроса, подскажите, пожалуйста, что Вы имеете в виду под "сетевой разведки"?

    Всего Вам самого доброго и успехов.
    С уважением,
    Наталия Рубан
    Менеджер Учебного центра "Информзащита"
    Тел. 937-3385 доб. 158
    RNO@itsecurity.ru
    www.itsecurity.ru

    *****************************************

    Уникальный авторский курс Учебного центра <Информзащита> - <Безопасность беспроводных сетей> http://www.itsecurity.ru/edu/kurs/bt_09.html
    ----------------------------------------------------------------

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

    Received: from convert.infosec.ru ([194.226.94.219]) by ukrserv.ustinfo.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
    id 454B7XWS; Fri, 15 Oct 2004 16:07:13 +0400
    Received: from nt_server.infosec.ru (unknown [200.0.0.5])
    by convert.infosec.ru (Postfix) with ESMTP id 43D3717FE8
    for <research@ustinfo.ru>; Fri, 15 Oct 2004 15:55:09 +0400 (MSD)
    Subject: =?koi8-r?B?UkU6IPrB0NLP0yDOwSDQ0sHK0w==?=
    X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
    Date: Fri, 15 Oct 2004 15:54:54 +0400
    Message-ID: <C5AD85826306B14CBB3DA801643F987BF73E33@nt_server.infosec.ru>
    From: "Natalya O. Ruban" <rno@itsecurity.ru>
    To: <research@ustinfo.ru>

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

    Антивирусные системы:
    X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A.
    X-AntiVirus: Checked by Dr.Web [version: 4.32, engine: 4.32, virus records: 53323, updated: 30.08.2004]
    X-AntiVirus: Checked by Dr.Web [version: 4.32a, engine: 4.32a, virus records: 53465, updated: 1.09.2004]
    X-RAV-Antivirus: This e-mail has been scanned for viruses on host: xs195-241-170-254.dial.tiscali.nl
    X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.37; host: postbode02.zonnet.nl)
    X-Virus-Scanned: by amavisd-milter at purinmail.com

    Антиспамовые системы:
    X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on frost.void.ru
    X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailhub.sibbereg.ru

    Однако, еще одна полученная нами информация это то, что сервер nt_server.infosec.ru - это Microsoft Exchange 2003.

    Об этом ясно говорит строка:
    X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0

    Вот далеко неполный список расшифровки числовых значений Microsoft MimeOLE:

    4.40.308 Internet Explorer 1.0 (Plus! for Windows 95)
    4.40.520 Internet Explorer 2.0
    4.70.1155 Internet Explorer 3.0
    4.70.1158 Internet Explorer 3.0 (Windows 95 OSR2)
    4.70.1215 Internet Explorer 3.01
    4.70.1300 Internet Explorer 3.02 and 3.02a
    4.71.544 Internet Explorer 4.0 Platform Preview 1.0 (PP1)
    4.71.1008.3 Internet Explorer 4.0 Platform Preview 2.0 (PP2)
    4.71.1712.6 Internet Explorer 4.0
    4.72.2106.8 Internet Explorer 4.01
    4.72.3110.8 Internet Explorer 4.01 Service Pack 1 (Windows 98)
    4.72.3612.1713 Internet Explorer 4.01 Service Pack 2
    5.00.0518.10 Internet Explorer 5 Developer Preview (Beta 1)
    5.00.0910.1309 Internet Explorer 5 Beta (Beta 2)
    5.00.2014.0216 Internet Explorer 5
    5.00.2314.1003 Internet Explorer 5 (Office 2000)
    5.00.2614.3500 Internet Explorer 5 (Windows 98 Second Edition)
    5.00.2516.1900 Internet Explorer 5.01 (Windows 2000 Beta 3, build 5.00.2031)
    5.00.2919.800 Internet Explorer 5.01 (Windows 2000 RC1, build 5.00.2072)
    5.00.2919.3800 Internet Explorer 5.01 (Windows 2000 RC2, build 5.00.2128)
    5.00.2919.6307 Internet Explorer 5.01 (Office 2000 SR-1)
    5.00.2920.0000 Internet Explorer 5.01 (Windows 2000, build 5.00.2195)
    5.00.3103.1000 Internet Explorer 5.01 SP1 (Windows 2000 SP1)
    5.00.3105.0106 Internet Explorer 5.01 SP1 (Windows 95/98 and Windows NT 4.0)
    5.00.3314.2101 Internet Explorer 5.01 SP2 (Windows 95/98 and Windows NT 4.0)
    5.00.3315.1000 Internet Explorer 5.01 SP2 (Windows 2000 SP2)
    5.00.3502.1000 Internet Explorer 5.01 SP3 (Windows 2000 SP3 only)
    5.00.3700.1000 Internet Explorer 5.01 SP4 (Windows 2000 SP4 only)
    5.50.3825.1300 Internet Explorer 5.5 Developer Preview (Beta)
    5.50.4030.2400 Internet Explorer 5.5 & Internet Tools Beta
    5.50.4134.0100 Internet Explorer 5.5 for Windows Me (4.90.3000)
    5.50.4134.0600 Internet Explorer 5.5
    5.50.4308.2900 Internet Explorer 5.5 Advanced Security Privacy Beta
    5.50.4522.1800 Internet Explorer 5.5 Service Pack 1
    5.50.4807.2300 Internet Explorer 5.5 Service Pack 2
    6.00.2462.0000 Internet Explorer 6 Public Preview (Beta)
    6.00.2479.0006 Internet Explorer 6 Public Preview (Beta) Refresh
    6.00.2600.0000 Internet Explorer 6 (Windows XP)
    6.00.2800.1106 Internet Explorer 6 Service Pack 1 (Windows XP SP1)
    6.00.3663.0000 Internet Explorer 6 for Microsoft Windows Server 2003 RC1
    6.00.3718.0000 Internet Explorer 6 for Windows Server 2003 RC2
    6.00.3790.0000 Internet Explorer 6 for Windows Server 2003 (released)

    Более полный список встроен в написанную мной утилиту UST.IEviaOLE, которая определяет используемый почтовый клиент от компании Microsoft и версию ОС отправителя письма. Утилита доступна для скачивания с сайта ustinfo.ru.

  10. Итог:
    Проведенные выше мероприятия сетевой разведки сервиса электронной почты компании НИП Информзащита создали предпосылки для проведения успешных атак на систему электронной почты компании. Они полностью раскрыли топологию как внешней сети, так и внутренней сети, точнее ее участков, участвующих в процессе обеспечения сервиса электронной почты. Мы узнали тип используемых серверов в компании, их количество и IP-адреса, в том числе и внутренние. То есть цели, поставленные в начале материала выполнены !

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

Задача разведки выполнена.
Переходим к второму пункту:
2. Проведение атаки на целевую систему.

...
CONNECTION ABORTED

Мы расшифровали формулу идеальной защиты!

Спойлер: она начинается с подписки на наш канал

Введите правильный пароль — подпишитесь!