Павел П. ака ukr-xblp. UST. [email protected] Сетевая разведка сегодня это неотъемлемая часть любого тестирования на проникновение (penetration testing). Если попытаться дать определение, что такое сетевая разведка, то я, пожалуй, согласился с таким: "сетевая разведка - есть комплекс мероприятий по получению и обработке данных об информационной системе клиента, ресурсов информационной системы, средств защиты, используемых устройств и программного обеспечения и их уязвимостях, а также о границе проникновения". Метод удаленного определения и/или получения информации об информационной системе, а именно получение типа и версии операционных систем на хостах сети, метод идентификации оборудования, программного обеспечения, сетевых сервисов и прочего известен как fingerprint (отпечаток пальца)/ снятие отпечатка. Т.е. некой уникальной последовательности (сигнатуры) какой-либо последовательности данных, уникальных для исследуемого объекта, по которой определение и возможно. Как вы уже поняли из названия, данная статья касается обнаружения типа, а в некоторых случаях и версий, программного обеспечения, обеспечивающих работу сервиса электронной почты, а именно протокола SMTP (протокола передачи электронной почты). Вкратце, опишу существующие ныне подходы к определению типа и версий smtp-серверов. 1й метод, самый распространенный и простой в реализации, это определение версии и типа сервера на основании сообщения, выдаваемого сервером при соединении с ним: telnet localhost 25 Trying 127.0.0.1... Connected to ns. Escape character is '^]'. 220 mail.ns ESMTP Sendmail 8.12.9p2/8.12.9; Thu, 22 Jun 2004 Метод получил название "banner grabbing" (сбор баннеров). Как мы видим на этом примере, при соединении сервер назвал нам свой тип (Sendmail) и версию (8.12.9). Однако, использование этого метода, не дает нам полной уверенности. Достоверность баннера всегда можно поставить под сомнение. Многие почтовые сервера предоставляют возможность изменять исходный баннер, чем не преминет воспользоваться администратор, следуя различным наставлениям по обеспечению безопасности. Также некоторые версии не выдают никаких баннеров или же администратор просто вместо строки баннера поставил пробел. Типичная для этого случая ситуация: telnet smtp.mail.ru 25 Trying 194.67.23.111... Connected to smtp.mail.ru. Escape character is '^]'. 220 mail.ru ESMTP Wed, 30 Jun 2004 13:22:25 +0400 Программно данный метод реализован в различных сканерах безопасности (ISS, Retina, GFI Languard). Некоммерческие продукты также используют его (NMAP, AMAP, VMAP). 2й метод, более технически сложный, к тому же, легко обнаруживаемый системами обнаружения вторжений, установленными в исследуемой сети, но однако уже более результативный и не зависит от информации, выдаваемой сервером при соединении, основан на том, что в rfc, описывающим протокол (RFC 821), приведены только коды команд, посему аналитик, послав некоторое число smtp-команд, получит разные варианты ответов на них, с разными значениями кодов и их описаниями. Сравним: Это типичный ответ SMTP сервера под управлением Sendmail на небольшое число стандартных команд: 220 mail.ns ESMTP Sendmail 8.12.9p2/8.12.9; Thu, 22 Jun 2004 helo 501 5.0.0 helo requires domain address helo ust 250 mail.ns Hello [192.168.1.1], pleased to meet you vrfy 501 5.5.2 Argument required vrfy ust 550 5.1.1 ust... User unknown mail 501 5.5.2 Syntax error in parameters scanning "" quit 221 2.0.0 mail.ns closing connection А это взятый для примера smtp-релей под управлением Checkpoint. 220 CheckPoint FireWall-1 secure SMTP server helo 250 Hello helo ust 250 Hello ust, pleased to meet you vrfy 250 User ok vrfy ust 250 User ok mail 501 Syntax error quit 221 Closing connection Как мы видим, различаются не только значения кодов (смотрим на результат ответа на команду "helo": 501 против 250) но и по описанию кодов ("501 5.5.2 Syntax error in parameters scanning "" против простого "501 Syntax error"). Следовательно процесс определении типа и версии в этом случае заключается в отправлении на сервер определенного, заранее сформированного списка команд smtp, в которых намеренно допущены различного рода искажения, вроде регистра, нарушения порядка команд, пропуск обязательных параметров, и сравнение полученных данных с собранной базой ответов smtp-серверов. Программно данная технология реализована в сканерах безопасности Nessus, Xspider, а также в утилитах, типа UST.Mail.Fingerprint.SMTP, Smtpmap, Smtpscan, VMAP и прочих. Но даже этот метод не дает нам стопроцентной уверенности в том, что результат нашего анализа соответствует действительности. Те же самые коды возврата и их описания часто изменяются администраторами почтовых серверов для противодействия данному виду атак. 3й метод, почти нигде и никем не описанный, и явился поводом к написанию данного материала. Метод основан на анализе данных, полученных от SMTP сервера, представленных в виде заголовка электронного письма. Посмотрим на типичный заголовок, точнее его часть, нужную нам: Received: from houseofcards.securiteam.com (securiteam.com [192.117.232.213]) by nt.mail with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NRN77NQ4; Thu, 29 Jun 2004 18:26:33 +0400 Если обратиться к RFC 821, то структура записи о пути письма будет выглядеть примерно так: Received: from ОТПРАВИТЕЛЬ by ПОЛУЧАТЕЛЬ with ПРОТОКОЛ ID, Date, Time, GMT Итак, что же вы видите примечательного в заголовке? Баннер сервиса, не так ли (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)? Но это же 1й способ, оговоренный выше. Даже если присмотритесь внимательнее, больше, наверное, ничего, чтобы позволяло судить о версии, не найдете. Для этого необходимо привести заголовок, но уже от другого сервера. Received: from imr1.srv.uk.deuba.com(10.141.44.110) by firewall via smap (V1.3) id sma029492; Tue Mar 31 09:00:36 Какие же мы можем видеть отличия? Обратите свое внимание на значение ID тага. NRN77NQ4 и sma029492 - разное количество символов; разный регистр символов; в первом случае использование букв и цифр повсеместное, во втором только первые 3 символа буквы. Обратите внимание на формат записи сообщения, вместо with SMTP, появилось via smap. Во всем RFC 821 формат ID описывается только одной (!) строчкой: ::= "ID" Следовательно, каждый разработчик почтовых серверов следует своему собственному формату. Давайте для себя создадим некую формулу, по которой мы составим уникальную последовательность, описывающую формат заголовка письма для smtp сервера: 1й символ: Если все символы в верхнем регистре, пишем 0, иначе, то 1. 2й символ: Если все символы тага являются цифрами, пишем 0, иначе 1. 3й символ: Если присутствуют спецсимволы в таге (дефис, к примеру), то пишем 0, иначе 1. 4й символ: Соответствует количеству символов в таге. Если следовать понятиям технологий fingerprinta, то такая формула будет называться сигнатурой. А теперь постараемся составить из них значение, описывающее ID таг в письме: тип (версия) smtp-сервера - пример ID тага - полученное значение. Microsoft Exchange Internet Mail Service - NRN77NQ4 - 0108 Postfix - A0AEE5A454 - 01010 Netscape Messaging Server - FFE6NF07.QA0 - 01112 CommuniGate Pro SMTP - 42575102 - 0008 Sendmail 8.12.* - h6CJd2J0010122 - 11014 Sendmail 8.11.* - i4Q9KDN19626 - 11012 Как вы видите, данные последовательности уникальны именно для этих серверов. Да, захотев поспорить со мной, вы найдете сервера, для которых данные последовательности будут совпадать. Но, к примеру, тот же UST.SITF (инструмент как раз для определения типа и версии сервера на основе заголовков) проводит анализ не по 4 пунктам, а по 11 (на момент написания данной статьи). Данный метод пригодится к использованию многим специалистам, проводящим сетевую разведку. Данный третий способ никоим образом не может быть (пока) обнаружен интеллектуальными системами обнаружения вторжений, так как не вызывает никаких аномалий. Он обеспечивает анонимность специалиста, проводящего исследование (вы же можете послать письмо и получить ответ на любой ящик бесплатной почтовой системы). P.S. в рабочей практике приходилось встречаться с системами, удаляющими информацию из заголовков письма, в том числе и ID таг P.P.S. Администраторы mail.ru сильно затруднили и почти свели на нет возможность определения типа серверов на своих системах при использовании первого и второго способа. Однако... Received: from mail by f26.mail.ru with local id 1BbOdV-0006Ap-00 id подобного типа соответствует почтовому серверу под управлением Exim. Источник:http://www.securitylab.ru
