...
...
...

сбор критических данных без вторжения

В этой статье речь пойдет о методах поиска технической информации, относящейся к конкретной системе, не привлекающих внимания IDS и администратора системы. Статья может оказаться полезной в ходе планирования испытаний на проникновение (penetration testing), а также содержит советы по предотвращению утечки критической информации, заслуживающие внимания системных администраторов.

О методах сбора информации написано немало, однако в основном рекомендации сводятся либо к соединениям с системой с исследованием сообщений от сервисов (banner-grabbing), либо к использованию социальной инженерии. Оба эти метода в большинстве случаев эффективны, однако, при наличии мало-мальски разумной политики безопасности, насторожат администратора.
Описанные ниже методы сбора информации отличаются как легальностью (даже простые подключения к портам могут быть расценены как неавторизованная деятельность — ведь в результате расходуется некое количество машинного времени), так и "прозрачностью" — без дополнительной "контрразведки" такая деятельность практически незаметна, и не может послужить "триггером" для принятия контрмер.
Будем исходить из минимального набора исходных сведений — IP адрес системы и ее хостнэйм. Естественно, все интересующиеся IT-безопасностью имеют представление о whois, DNS lookup, finger, traceroute, и так далее. В то же время, нет никакой необходимости делать запросы непосредственно со своей машины — существует ряд онлайн-инструментов, реализованных как CGI- или PHP-скрипты, с помощью которых можно осуществить запрос с разнообразных удаленных и от "мишени", и от "стрелка" серверов. С перспективы "прозрачной разведки" весь интернет можно представить одним распределенным инструментом для сбора информации — в нашем случае, информации, раскрытие которой может оказаться критическим для безопасности системы.
Естественно, использование онлайн-скриптов — не новость, и является только первым этапом рассматриваемой стратегии. На этом этапе мы получаем первый блок информации, абсолютно безвредной , но в то же время — это та самая печка, от которой уже можно плясать: e-mail администратора, название организации, название хостинга, адреса DNS и так далее.
Следующий этап — сбор информации о конфигурации системы. Опять-таки с помощью онлайн-инструментов можно получить информацию об используемой операционной системе. В случае наличия веб-сервера лишний раз проверить полученную информацию можно, используя просто браузер Netscape или Mozilla — в его кэше сохраняется запись вроде

Apache/1.3.28 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.2 PHP/4.3.3 FrontPage/5.0.2.2634 mod_ssl/2.8.15 OpenSSL/0.9.7a

На сайте хостинга нередко можно найти техническую информацию о сервере — вплоть до топологии сети

.
(Рис. 1)

На иллюстрации (см. рис. 1), находившейся в открытом доступе, удалена идентифицирующая конкретную сеть информация. Как можно видеть, опубликованы даже модели оборудования.
Здесь начинается разведка как таковая — мы берем каждый кусочек полученной информации и проводим поиск по этой строке, например, по e-mail администратора, его имени, хостнэйму системы и так далее. Это ключ к серьезному объему информации. Так, в ходе консультации, проводимой мной для некой весьма известной компании, поиск по взятому с whois адресу администратора местного филиала показал его пост в форуме крупного IT-security портала Neophasis, где на приличном английском излагались его проблемы с конфигурацией защитных средств и подробно описывалось используемое ПО. /* Метод, кстати, совершенно замечательный. Не надо далеко ходить за примерами: запросите whois-информацию о блоке(ах) адресов вашего ISP (можно upstream-провайдера), возьмите контактные данные технического админитсратора (в RIPE’овской базе это поле называется tech-c) и распросите о нем Google. Бьюсь об заклад, вы узнаете массу интересного ;) — прим. ред. */
Поиск по хостнэйму может привести к логам прокси-серверов, нередко содержащим полезную информацию.
Системным администраторам (администраторам безопасности) можно посоветовать включить следующие требования в политику безопасности:
— не использовать один и тот же адрес для регистрации домена и в открытом для посторонних глаз обсуждении технических деталей;
— в обсуждениях с посторонними специалистами через Интернет, которые, несомненно, могут стать чрезвычайно продуктивными, безопаснее использовать "аватар", или "альтернативную личность", не раскрывая своего подлиного имени и места работы;
— модифицировать баннеры сервисов; так, администратор известного затяжными сражениями с хакерами сайта RIAA.org изменил баннер Microsoft IIS 6.0 на TST-SECURE-OS (другое дело, что при этом каталог /admin не был защищен должным образом :).
А теперь — конкретный пример "прозрачной разведки", проведенной специально для этой статьи. Так как не ставилась задача выявить все уязвимости или получить на системе привилегии, предприняты шаги исключительно демонстрационного характера. В примере я использую хостнэйм, присланный мне спаммерами — laserjet.ru. Коль скоро господа, управляющие этим сайтом, прибегают к невостребованной рассылке (видимо, от недостатка общения ;), логично будет предположить, что они не имеют ничего против некоторой известности :)

Итак, laserjet.ru:
IP-адрес:69.56.138.130;
Веб-сервер:Apache/1.3.29 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.2 PHP/4.3.3 FrontPage/5.0.2.2634 mod_ssl/2.8.16 OpenSSL/0.9.7a;
ОС:Linux (точнее определить можно с помощью средств passive OS fingerprinting /* можно и active, если не страдаешь паранойей ;) — прим. ред */).
Из ответа nslookup узнаем email администратора DNS: root.laserjet.ru /* не все заполняют это поле реальными данными, еще более немногие следят за актуальностью данных в этом поле — прим. ред. */
Вот и логин: root. Доверчиво вбив адрес, какой не жалко, в форму на сайте, получаем с ответным письмом еще один логин, info, а также видим в заголовке: Received: from 69.56.138.130 (EHLO mustang.ipaska.net).
Следующим шагом узнаем о хостинге ipaska.com и читаем об его сервисах, в частности: «...Network Operation Centers use industry-standard SNMP... ....All critical services/ports are monitored, including FTP, HTTP, SMTP, HTTPS, SSH and POP3.”
Вот и ftp-сервер: mustang.ipaska.net:21 PureFTPd 1.0.12 (разрешен анонимный доступ).
Теперь «зайдем с другого боку»: whois laserjet.ru: org: Suntor Limited e-mail: jhnsmith50@hotmail.com.
Поиск по двум последним строкам показал еще один домен с такими же регистрационными данными — pointer.ru. Любопытный домен, надо отметить, особенно субдомены:

ad.pointer.ru195.161.119.193
icq.pointer.ru195.161.119.193
mail.pointer.ru81.176.69.152

mail2.pointer.ru195.161.119.193
ms.pointer.ru195.161.119.193
ns.pointer.ru81.176.69.152
ns2.pointer.ru195.161.119.193
popup.pointer.ru195.161.119.193


195.161.119.193 также определяется как virtual193.damochka.ru.
Веб-сервер:Apache/1.3.29 (Unix) mod_gzip/1.3.19.1a mod_perl/1.27 PHP/4.3.4RC1;
ОС:FreeBSD;
логин: info (логично предположить, что раз у laserjet.ru существуют логины root и info, то здесь такая же ситуация и существует логин root).
Так как мы видим mail.pointer.ru и mail2.pointer.ru, можно отправить письмо несуществующему пользователюspammustdie@pointer.ru. В ответе-сообщении об ошибке видим:
Remote-MTA:dns; mail.pointer.ru (81.176.69.152|25|....)
То есть имеется SMTP-сервер на порту 25. В план дальнейшего исследования можно включить, в частности, получение списка логинов через SMTP командой EXPN. В принципе, обращения к SMTP-серверу уже несколько выходят за рамки данной статьи.
DNS-сервер:ns.pointer.ru.
Хосты ad.pointer.ru и popup.pointer.ru могут пополнить собой банлисты средств борьбы с онлайн-рекламой :) Несколько озадачили icq.pointer.ru (крайне бессвязно наполненный, с точки зрения контента; с маркетинговой точки зрения — все понятно) и ms.pointer.ru — редирект на microsoft.com. Microsoft прибегает к услугам спаммеров? index этого сайта — копия заглавной страницы microsoft.com.
Поиском обнаружен также адрес popup.pointer.ru:8080 — предположительно прокси-сервер :) Суммарно: исходя из хостнэйма laserjet.ru, из открытых источников получены:
laserjet.ru:2 логина, тип OC, HTTP и FTP серверов, краткий список используемых хостером сервисов, 9 принадлежащих той же компании хостнэймов *.pointer.ru;
pointer.ru:логин (предположительно 2), наличие SMTP- и proxy-сервисов на определенных портах, тип OC и веб-сервера, информация о "странных" icq.pointer.ru и ms.pointer.ru. Собранная информация теоретически может быть использована как сетевым активистом для легального преследования спаммеров и затруднения их деятельности, так и хакером для получения повышенных привилегий на указанных системах — любой sсriptkiddie в состоянии найти эксплойт, зная тип и версию ПО.

редакционное послесловие


If you are paranoid, are you paranoid ENOUGH? Эта расхожая фраза запросто могла бы быть эпиграфом для данной статьи. Но, поскольку мне кажется несколько некорректным присобачивать эпиграфы к чужим статьям, пусть это будет эпиграф для послесловия :)
Эта прекрасная, на мой взгляд, статья содержит корректную как с технической, так и с логической точки зрения информацию, но в ней есть есть вещи, которые меня очень и очень настораживают.
Во-первых, ремарка «даже простые подключения к портам могут быть расценены как неавторизованная деятельность — ведь в результате расходуется некое количество машинного времени».
Ситуация: некий хост выведен в Интернет, на нем работают сервисы. Если на нем эти сервисы работают — значит это кому-то нужно, иначе зачем они там, huh? И что же это получается: если мы кликаем на ссылку «послать письмо» на сайте компании и посылаем письмо на данный хост (используем, стало быть, сервис SMTP) — мы «хорошие» и «авторизованные», а если мы запросто так лезем телнетом на тот же 25 порт, скажем, посмотреть версию демона или отправить письмо «вручную» (например, postmaster’у) — то мы уже «хакеры».
IMHO если кто-то выставил хост во всемирную глобальную, он должен быть готов к расходу «некого количества машинного времени». А уж если это «некое количество» не удовлетворяет хозяина хоста, он должен принять меры по сокращению своих затрат в этой области, а никак не перекладывать с большой головы на здоровую: «я не планировал, что вы будете обращаться к моей машине так-то и так-то, значит такое обращение противозаконно».

______________________________________________________________________________________

глас народа

<fish>скажите такую вещь: какой утлитой можно получить список днс-записей о конкретном хосте (mail.ru например)?
<TheCat>host -a mail.ru
<pulsar_>fish> dig и host
<wall>вопрос не простой — зачем тебе это?
<pulsar_>тестирование
<wall>чего
<wall>такая вещица в руках неумеющего страшная сила
<wall>я не на кого не намекнул !
<wall>в смысле страшная потому что если дальше пойдёшь придут дяди и руку заломают
<TheCat>это вы о чем?
<wall>да так вспомнил прошлое
<TheCat>про диг и хост?
<wall>нет про хакинг и маки
<wall>слыште вы крутые хакеры
<wall>я ламером не прикидываюсь а что говорю то раньше делал...
...
______________________________________________________________________________________


Во-вторых, совершенно опечалил, я бы даже сказала — обескуражил меня следующий абзац:
«Естественно, все интересующиеся IT-безопасностью имеют представление о whois, DNS lookup, finger, traceroute, и так далее. В то же время, нет никакой необходимости делать запросы непосредственно со своей машины...»
Упс, приехали: стандартные утилиты и методы сетевого анализа (мало относящиеся к сфере IT-безопасности) постепенно переползают в сферу недозволенного? И такие вещи уже не рекомендуется исполнять со своей машины? То бишь, если моя сеть (хост) А не имеет доступа к сети (хосту) Б, мне следует обратиться к саппорту своего провайдера, сложить ручки и смиренно ждать, пока «починют» или сообщат причину «бессвязности» сетей? Да уж, любой тоталитарный режим позавидовал бы ущемлению свобод, которое пользователи Интернет творят над собой своими же собсвенными руками (см. также лог irc-чата во врезке «Глас народа»).
Кстати, кроме восстановления связности сетей, диангостические утилиты и методики могут использоваться и для исследовательской работы. Netcraft ведет учет популярности веб-серверного ПО, кого-то может заинтересовать процент почтовых систем, поддерживающих тот или иной функционал. Могут быть и очень частные исследования: например, обманывает ли потенциального клиента реклама сервис-провайдера (обладает ли он заявленными мощностями) или что представляет собой тот или иной Интернет-проект, откуда там «ноги растут», где хостится, кто им владеет, и, стало быть, стоит ли с ними иметь дело.
Кто-то из гуру в области IT-безопасности как-то заметил, что если ты разглядываешь витрину магазина — это не значит, что ты готовишь ограбление. С другой стороны, если ты боишься, что в твое окно будут пялиться прохожие — повесь шторы. И это правильно.
Автор статьи показывает, какими методами можно пользоваться для получения информации о вас, вы можете сделать соответсвующие выводы и, если считаете нужным, противостоять «негласному съему информации».
Мне же просто хотелось обратить внимание общественности на то, что деятельность исследовательская !== злоумышленная деятельность. Перечисленные в статье методы, равно как и многие другие (скажем, сканирование портов или active OS fingerprinting) не должны получать статус недозволенных — ни де юре, ни де факто. Не хотелось бы через пару десятков лет оказаться перед фактом существования вокруг нас Всемирного Виртуального Третьего Рейха %)
P.S.: мое мнение противоречит некоторым пунктам документа OFISP-008 "Нормы пользования сетью". Я, в общем-то, этого никогда и не скрывала ;)

ALiEN Assault, примечания и редакционное послесловие Alice D. Saemon..


© Сетевые решения