Текст книги "Спецвыпуск журнала «Хакер» 47, октябрь 2004 г."

Автор книги: Хакер Журнал

сообщить о нарушении

Текущая страница: 11 (всего у книги 21 страниц)

База данных под прицелом / Взлом БД

Крис Касперски aka мыщъх

Данные – это основа всего. Тут и номера кредитных карт, и личная информация пользователей, и сведения об угнанных машинах. Содержимое чатов и форумов тоже хранится в БД. Проникновение в корпоративную (военную, правительственную) базу данных – самое худшее, что только может случиться с компанией. Поразительно, но даже критические сервера зачастую оказываются никак не защищены и взламываются 12-летними любителями командной строки без особых усилий.

Введение

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

Размещать сервер базы данных на одном узле с Web-сервером категорически недопустимо не только по техническим, но и по юридическим соображениям (законодательства многих стран диктуют свою политику обращения с конфиденциальными данными, особенно если эти данные хранят информацию о клиентах компании). Тем не менее, совмещение сервера БД с Web-сервером довольно обычно из-за экономии. Захватив управление Web-сервером (а практически ни одному Web-серверу не удалось избежать ошибок переполнения буфера и прочих дыр), атакующий получит доступ ко всем данным, хранящимся в базе!

Сервер БД, как и любой другой сервер, подвержен ошибкам проектирования, среди которых доминируют переполняющиеся буфера, позволяющие атакующему захватывать управление удаленной машиной с наследованием администраторских привилегий. Яркий пример тому – уязвимость, обнаруженная в сервере MS SQL и ставшая причиной крупной вирусной эпидемии. Не избежал этой участи и MySQL. Версия 3.23.31 падала на запросах типа select a.AAAAAAA…AAAAAA.b, а на соответствующим образом подготовленных строках – передавала управление на shell-код, причем атаку можно было осуществить и через браузер, передав в URL уязвимому для SQL-инъекции скрипту что-то типа: script.php?index=a.(shell-code).b.

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

Нестойкость шифрования паролей

Пароли, регламентирующие доступ к базе данных, ни при каких обстоятельствах не должны передаваться открытым текстом по сети. Вместо пароля передается его хэш, зашифрованный случайно сгенерированной последовательностью байт и называемый проверочной строкой (check-string). Короче говоря, реализуется классическая схема аутентификации, устойчивая к перехвату информации и при этом не допускающая ни подбора пароля, ни его декодирования, во всяком случае, в теории.

На практике же во многих серверах БД обнаруживаются грубые ошибки проектирования. Взять хотя бы MySQL версии 3.x. Хэш-функция, используемая для «сворачивания» пароля, возвращает 64-разрядную кодированную последовательность, в то время как длина случайно генерируемой строки (random-string) составляет всего лишь 40 бит. Как следствие, шифрование не полностью удаляет всю избыточную информацию и анализ большого количества перехваченных check-string/random-string позволяет восстановить исходный хэш (пароль восстанавливать не требуется, так как для аутентификации он не нужен).

В несколько упрощенном виде процедура шифрования выглядит так:

ЛИСТИНГ

// P1/P2 – 4 левых/правый байта парольного хэша соответственно

// C1/C2 – 4 левых/правый байта random-string соответственно

seed1 = P1 ^ C1;

seed2 = P2 ^ C2 ;

for(i = 1; i <= 8; i++)

{

seed1 = seed1 + (3*seed2);

seed2 = seed1 + seed2 + 33;

r[i] = floor((seed1/n)*31) + 64;

}

seed1 = seed1+(3*seed2);

seed2 = seed1+seed2+33;

r[9] = floor((seed1/n)*31);

checksum =(r[1]^r[9] || r[2]^r[9] || r[7]^r[9] || r[8]^r[9]);

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

Перехват пароля

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

Многие сервера хранят информацию об авторизации в кукисах (cookie), находящихся на машинах удаленных пользователей, и, вместо того чтобы ломиться на хорошо защищенный корпоративный сервер, взломщик может атаковать никем не охраняемые клиентские узлы. Главная трудность заключается в том, что их сетевые координаты наперед неизвестны и атакующему приходится тыкаться вслепую. Обычно эта проблема решается массированной рассылкой почтовой корреспонденции с троянизированным вложением внутри по многим адресам – если повезет, то среди пользователей, доверчиво запустивших трояна, окажется хотя бы один корпоративный клиент. Ну а извлечь куки – уже дело техники.

Некоторые серверы баз данных (в частности, ранние версии MS SQL), автоматически устанавливают пароль по умолчанию, предоставляющий полный доступ к базе и позволяющий делать с ней что угодно (у MS SQL этот пароль «sa»).

Навязывание запроса, или SQL-инъекция

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

ЛИСТИНГ

$result = mysql_db_query(«database», "select * from userTable

where login = «$userLogin» and password = «$userPassword»);

Здесь $userlogin – переменная, содержащая имя пользователя, а $userPassword – его пароль. Обрати внимание, что обе переменные размещены внутри текстовой строки, окаймленной кавычками. Это необычно для Си, но типично для интерпретируемых языков вроде Perl и PHP. Подобный механизм называется интерполяцией строк и позволяет автоматически подставлять вместо переменной ее фактическое значение.

Допустим, пользователь введет KPNC/passwd. Тогда строка запроса будет выглядеть так: «select * from userTable where login = 'KPNC' and password = 'passwd'».

Если такой логин/пароль действительно присутствует в базе, функция сообщает идентификатор результата, в противном случае возвращается FALSE.

Хочешь войти в систему под именем другого пользователя, зная его логин, но не зная пароль? Воспользуйся тем, что механизм интерполяции позволяет атакующему воздействовать на строку запроса, видоизменяя ее по своему усмотрению. Посмотрим, что произойдет, если вместо пароля ввести последовательность «fuck' or '1'= '1» (без кавычек): «select * from userTable where login = 'KPNC' and password = 'fuck' or '1' = '1'».

Смотри: кавычка, стоящая после fuck, замкнула пользовательский пароль, а весь последующий ввод попал в логическое выражение, навязанное базе данных атакующим. Поскольку один всегда равен одному, запрос будет считаться выполненным при любом введенном пароле и SQL-сервер возвратит все-все-все записи из таблицы (в том числе и не относящиеся к логину KPNC)!

Рассмотрим другой пример: «SELECT * FROM userTable WHERE msg='$msg' AND ID=669».

Здесь msg – номер сообщения, извлекаемого из базы, а ID – идентификатор пользователя, автоматически подставляемый скриптом в строку запроса и непосредственно не связанный с пользовательским вводом. Константная переменная использована по соображениям наглядности, в конечном скрипте будет, скорее всего, использована конструкция типа: ID='$userID'. Чтобы получить доступ к остальным полям базы (а не только к тем, чей ID равен 669), необходимо отсечь последнее логическое условие. Это можно сделать, внедрив в строку пользовательского ввода символы комментария («-» и «/*» для MS SQL и MySQL соответственно). Текст, расположенный правее символов комментария, игнорируется. Если вместо номера сообщения ввести «1' AND ID=666 -», строка запроса примет следующий вид: «SELECT * FROM userTable WHERE msg='1' and ID= 666 -' AND ID=669» .

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

Причем одним лишь видоизменением полей SELECT'а дело не огранивается, и существует угроза прорыва за его пределы. Некоторые SQL-сервера поддерживают возможность задания нескольких команд в одной строке, разделяя их знаком «;„, что позволяет атакующему выполнить любые SQL-команды, какие ему только заблагорассудится. Например, последовательность « '; DROP TABLE 'userTable' -“, введенная в качестве имени пользователя или пароля, удаляет всю userTable!

Еще атакующий может сохранять часть таблицы в файл, подсовывая базе данных запрос типа «SELECT * FROM userTable INTO OUTFILE 'FileName'». Соответствующий ему URL уязвимого скрипта может выглядеть, например, так: www.victim.com/admin.php?op=login&pwd=123&aid=Admin'%20INTO%20OUTFILE%20'/path_to_file/pwd.txt, где path_to_file – путь к файлу pwd.txt, в который будет записан админовский пароль. Удобное средство для похищения данных, не так ли? Главное – размесить файл в таком месте, откуда его потом будет можно беспрепятственно утянуть, например, в одном из публичных WWW-каталогов. Тогда полный путь к файлу должен выглядеть приблизительно как: «../../../../WWW/myfile.txt» (точная форма запроса зависит от конфигурации сервера). Но это еще только цветочки! Возможность создания файлов на сервере позволяет засылать на атакуемую машину собственные скрипты (например, скрипт, дающий удаленный shell – « »). Естественно, максимальный размер скрипта ограничен предельно допустимой длиной формы пользовательского ввода, но это ограничение зачастую удается обойти ручным формированием запроса в URL или использованием SQL-команды INSERT INTO, добавляющей новые записи в таблицу.

Скорректированный URL-запрос может быть таким: http://www.victim.com/index.php?id=12 или таким: http://www.victim.com/index.php?id=12+union+select+null,null,null+from+table1 /*.

Последний запрос работает только на MySQL версии 4.х и выше, поддерживающей union (объединение нескольких запросов в одной строке). Здесь table1 – имя таблицы, содержимое которой необходимо вывести на экран.

Атаки подобного типа называются SQL-инъекциями (SQL-injection) и являются частным случаем атак, основанных на ошибках фильтрации и интерполяции строк. Мы словно впрыскиваем в форму запроса к базе данных собственную команду, прокалывая хакерской иглой тело уязвимого скрипта (отсюда и «инъекции»). Это не ошибка SQL-сервера (как часто принято считать). Это – ошибка разработчиков скрипта. Грамотно спроектированный скрипт должен проверять пользовательский ввод на предмет присутствия потенциально опасных символов (одиночная кавычка, точка с запятой, двойное тире, а для MySQL еще и символ звездочки) включая и их шестнадцатеричные эквиваленты, задаваемые через префикс «%», а именно: %27, %2A и %3B. Если хотя бы одно из условий фильтрации не проверяется или проверяется не везде (например, остаются не отфильтрованными строки URL или cookie), в скрипте образуется дыра, через которую его можно атаковать.

Впрочем, сделать это будет не так уж и просто. Необходимо иметь опыт программирования на Perl/PHP и знать, как может выглядеть та или иная форма запроса и как чаще всего именуются поля таблицы, в противном случае интерполяция ни к чему не приведет. Непосредственной возможности определения имен полей и таблиц у хакера нет, и ему приходится действовать методом слепого перебора (blinding).

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

Приблизительная стратегия поиска дыр выглядит так. Скачиваем исходные тексты PHP Nukе (или любой другой портальной системы), устанавливаем их на свой локальный компьютер, проходимся глобальным поиском по всем файлам, откладывая в сторонку все те, что обращаются к базе данных (вызов типа mysql_query/mysql_db_query или типа того). Далее прокручиваем курсор вверх и смотрим – где-то поблизости должна быть расположена строка запроса к базе (например: $query = «SELECT user_email, user_id FROM ${prefix}_users WHERE user_id = '$cookie[0]'»). Определяем имена переменных, подставляемых в базу, находим код, ответственный за передачу параметров пользовательского ввода и анализируем условия фильтрации.

В качестве наглядного примера рассмотрим одну из уязвимостей PHP Nuke 7.3, связанную с обработкой новостей. Соответствующий ей URL выглядит так: modules.php?name=News&file=categories&op=newindex&catid=1. По его внешнему виду можно предположить, что значение catid передается непосредственно в строке запроса к БД, и, если разработчик скрипта забыл о фильтрации, у нас появляется возможность модифицировать запрос по своему усмотрению. Для проверки этого предположения заменим catid с 1, допустим, на 669. Сервер немедленно отобразит в ответ пустой экран. Теперь добавим к нашему URL следующую конструкцию «'or'1'1='1» (полностью он будет выглядеть так: modules.php?name=News&file=categories&op=newindex&catid=669'or'1'='1). Сервер послушно отобразит все новостные сообщения раздела, подтверждая, что SQL-инъекция сработала!

Еще можно попытаться вызвать ошибку SQL, подсунув ей заведомо неправильный запрос (например, символ одиночной кавычки), и тогда она может сообщить много интересного. Отсутствие ошибок еще не означает, что скрипт фильтрует пользовательский ввод: быть может, он просто перехватывает сообщения об ошибках, что является нормальной практикой сетевого программирования. Также возможна ситуация, когда при возникновении ошибки возвращается код ответа 500 или происходит переадресация на главную страницу. Подобная двусмысленность ситуации существенно затрудняет поиск уязвимых серверов, но отнюдь не делает его невозможным!

Анализ показывает, что ошибки фильтрации встречаются в большом количестве скриптов (включая коммерческие), зачастую оставаясь неисправленными годами. Естественно, дыры в основных полях ввода давным-давно заткнуты, а потому рассчитывать на быстрый успех уже не приходится. Запросы, передаваемые методом POST, протестированы значительно хуже, поскольку передаются скрыто от пользователя и не могут быть модифицированы непосредственно из браузера, отсекая армаду начинающих «хакеров». Между тем, взаимодействовать с Web-сервером можно и посредством netcat (telnet), формируя POST-запросы вручную.

Заключение

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

Вскрытие скрипта

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

Подробнее об этом можно прочитать в моей статье «Безопасное программирование на языке Perl» (kpnc.opennet.ru/safe.perl.zip).

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

ЛИСТИНГ

…

if ($filename eq «passwd») #проверка имени на корректность

…

Определение наличия SQL

Прежде чем начинать атаку на SQL-сервер, неплохо бы определить его присутствие, а в идеале – еще и распознать тип. Если сервер расположен внутри DMZ (где ему находиться ни в коем случае нельзя), то атакующему достаточно просканировать порты.

Противодействие вторжению

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

Одним из таких средств является Security Scanner, разработанный компанией Application Security и официально предназначенный для тестирования MySQL на стойкость к взлому. Ну, хакерам официоз не грозит. Как и всякое оружие, Security Scanner может использоваться и во вред, и во благо.

Он позволяет искать дыры как в самом сервере БД, так и в Web-скриптах. При этом БД проверятся на предмет уязвимости к атакам типа Denial of Service, наличия слабых паролей, неверно сконфигурированных прав доступа и т.д. В скриптах сканер позволяет обнаружить ошибки фильтрации ввода, позволяющие осуществлять SQL-инъекции, что значительно упрощает атаку.

Мнение эксперта

Никита Кислицин, редактор рубрики «Взлом» журнала «Хакер»:

«Базы данных всегда были лакомым кусочком для хакеров. И в этом нет ничего удивительного: в них можно найти миллионы номеров кредитных карт, пароли к сетевым ресурсам, конфиденциальную информацию и даже планы террористических организаций по захвату цивилизованного мира. Увы, порой администраторы сетевых баз данных не уделяют должного внимания безопасности, часто их подводят и программисты, разрабатывающие программные интерфейсы. Следует знать, что в более чем половине случаев взлома SQL-серверов используется технология SQL-инъекции в разных ее проявлениях, то есть эти проблемы лежат на совести Web-программистов. Однако бывают и вовсе комические случаи. За примером далеко ходить не надо. „Xакер“ недавно писал о взломе cygwin.com и экспроприации оттуда вкуснейшей базы данных. Высокопрофессиональный админ этого сервера почему-то решил не указывать вообще никакого пароля к администраторскому аккаунту MySQL, что и позволило нашему партизану при помощи детского бага в скрипте совершить столь дерзкую вылазку».

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

Сервер БД, как и любой другой сервер, подвержен ошибкам проектирования, среди которых доминируют переполняющиеся буфера.

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

Почти 30% всех скриптов в сети подвержены ошибке SQL-инъекции.

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

Сетевая дактилоскопия / Технология remote fingerprinting

Антон Карпов ([email protected])

Идея удаленно определять версию ОС или запущенного на хосте сервиса не нова. Все знают, что популярный сканер nmap, будучи запущенным с параметром -O, пытается определить версию операционки. Известно также, что около года назад тот же nmap научился определять и версии сервисов, запущенных на сканируемом хосте. Наша задача – понять технологию работы сканера, а также убедиться в том, что одним лишь nmap'ом понятие fingerprinting не ограничивается.

Пакетные игры

Сканер nmap, запущенный с повышенной вербозностью (параметр -vvv), выдает примерно следующее:

ЛИСТИНГ

TCP/IP fingerprint:

SInfo(V=3.55%P=i386-portbld-freebsd6.0%D=7/29%Time=410833C8%O=21%C=-1)

T1(Resp=Y%DF=Y%W=FFFF%ACK=S++%Flags=AS%Ops=MNWNNT)

T2(Resp=N)

T3(Resp=N)

T4(Resp=Y%DF=Y%W=0%ACK=S++%Flags=R%Ops=)

T5(Resp=N)

T6(Resp=N)

T7(Resp=N)

PU(Resp=N)

Многие не обращают внимания, а ведь в этом кажущемся мусоре и содержится вся сермяжная правда об операционке. Это результаты восьми тестов для определения версии ОС; их, разумеется, намного больше, но мы рассмотрим только стандартные. Никто не сможет рассказать о них более подробно, чем Fyodor в своей статье, которая была опубликована в езине Phrack #54 в далеком 1998 году.

Первая строчка – просто информация о системе, на которой работает nmap, версия сканера, оси, на которой он собран, и т.п.

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

Итак, первый тест – это отправка пакета с установленным флагом SYN на открытый порт. Это штатный запрос, и система обязана на него прореагировать. Ответ (в скобках) интерпретируется следующим образом. Resp=Y означает, что от системы был получен ответ. DF=Y означает, что бит Don't Fragment, выставленный в отправленном пакете, сохранился. W – размер окна (Window Size) удаленной системы. ACK – значение Acknowledge Number в ответном пакете, S++ говорит о том, что оно было равно полученному ISN (Initial Sequence Number), увеличенному на 1. Flags – флаги в ответном пакете (в нашем случае это SYN+ACK). Ops – TCP-опции (временная метка, Max Segment Size и прочее), для nmap важно не только их наличие, но и порядок следования – .

Второй и третий тесты (T2 и T3) посылают NULL-пакет (без единого флага) и пакет с установленными флагами SYN, FIN, PSH и URG на открытый порт. Как видно, система не ответила на эти запросы (Resp=N).

T4 – отправка на открытый порт пакета с установленным флагом ACK. По стандарту, описанному в документах RFC, система должна ответить RST-пакетом, так как отправляемое сканером «подтверждение» (Acknowledgment) не связано ни с одним сеансом. Ответ получен (Resp=Y), бит Don't Fragment выставлен, размер окна – 0, из TCP-флагов установлен только RST (Reset connection), чего и следовало ожидать.

Тесты 5, 6 и 7 – также из серии «ненормальных». Пятый тест (T5) отправляет пакет с флагом SYN (но без ACK) на закрытый порт машины. Шестой – то же самое, только теперь вместо SYN установлен ACK. Седьмой – отправка пакета с выставленными флагами FIN, PSH, URG все на тот же закрытый порт. Наконец, последний тест (PU) – отправка ICMP-сообщения Port Unreachable на закрытый порт удаленной машины.

В четырех последних случаях ответ от хоста не был получен, но, так как ОС все равно опознана как FreeBSD, можно сделать вывод, что админ включил tcp & udp blackholes (sysctl -w net.inet.tcp.blackhole=2, sysctl -w net.inet.udp.blackhole=1), метод, при котором FreeBSD старательно игнорирует провокации ее неправильными пакетами. Догадка верная, ведь админ – я ;). Кстати, помни, что несанкционированное сканирование часто формально считается попыткой проникновения.Самый простой способ fingerprinting, не требующий никаких нестандартных инструментов, – это сбор баннеров (banner grabbing). Сервисы (www, ftp, smtp, pop3) готовы рассказать о себе все в ответ на простое подключение телнетом:

ЛИСТИНГ

[(2:00)(258.29%)(p2):~ ] telnet www.berkeley.edu 80

Trying 169.229.131.109…

Connected to arachne.berkeley.edu.

Escape character is '^]'.

HEAD / HTTP/1.0

HTTP/1.1 403 Forbidden

Date: Tue, 24 Aug 2004 22:04:03 GMT

Server: Stronghold/3.0 Apache/1.3.22 RedHat/3017c (Unix) PHP/4.3.3 mod_ssl/2.8.7 OpenSSL/0.9.6 mod_perl/1.25

Connection: close

Content-Type: text/html; charset=iso-8859-1

Однако многие сервисы позволяют штатным образом сменить баннер, так что данный метод нельзя назвать надежным. К тому же, далеко не все сервисы позволяют вести диалог в подобном plain-text режиме. И если даже nmap очень часто считает достаточным запросить баннер, греша точным определением FTP или DNS-сервера, то как же, например, популярный сканер XSpider (www.ptsecurity.ru) точно отличает Postfix от Sendmal, а vsftpd от proftpd?

Дело в том, что в документах RFC, описывающих поведение серверов, есть указания лишь по кодам выдаваемых в ответ на запросы клиентов ошибок, но не накладывается никакого ограничения на текстовую информационную составляющую. Так, на одну и ту же неверную команду Postfix ответит 500 Error: bad syntax, тогда как Sendmail – 500 5.5.1 Command unrecognized: «COMMAND_YOU_TYPE». Помучив сервер запросами и собрав базу возвращенных кодов, можно с достаточной точностью определить версию сервиса.

Но иногда все бывает еще проще, и вместе с сервисом становится известна версия ОС. Особенно этим грешат FTP-сервера:

ЛИСТИНГ

[(3:51)(85.32%)(p1):~ ] ftp [email protected]

Connected to 19X.XX.1.20X.

220 beast FTP server (Version 1.7.212.1 Sat Feb 1 01:30:15 GMT 1997) ready.

331 Password required for toxa.

Password:

230 User toxa logged in.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> syst

215 UNIX Type: SUNOS

ftp> quit

221 Goodbye.

Как видно, FTP-сервер не только сообщил, что уже семь лет ждет эксплоита, но и заодно признался, что запущен на солярке.

Для сервисов, текстовый диалог с которыми невозможен, (например, DNS-сервер) применяется та же технология: на сервер посылаются неверные запросы и анализируются ответные пакеты. Просто реализация такого анализа немного сложнее.

Пассивный fingerprinting

Как насчет того, чтобы определить версию сервиса, не послав на целевой хост ни единого пакета? На ум сразу же приходят банальный снифер на пути до хоста и дальнейший анализ перехваченных пакетов. Такие технологии применяются уже давно (http://project.honeynet.org/papers/finger/) и работают по тому же принципу, что и nmap (анализируются поля в заголовках пакета).

Для SMTP-серверов существуют методы, не требующие ничего, кроме одного письма, прошедшего через целевой сервер. Многие сервера вставляют в письма красноречивые рабочие заголовки:

ЛИСТИНГ

Received: from [email protected] by mercury.xxxxxx.ru by uid 0 with qmail-scanner-1.22

(clamscan: 0.75. spamassassin: 2.63. Clear:RC:0(xx3.1xx.8x.14xx):SA:0(0.0/7.0):

По ним мы сразу определяем, что на сервере крутится qmail, сдобренный солянкой из qmail-scanner и SpamAssassin.

Есть элегантный способ, описанный российской security-группой UkR Security Team (http://www.securitylab.ru/46232.html). Он основан на анализе id-тега в заголовке письма. Как и в случае с кодом ошибки, rfc не накладывает никаких ограничений на алгоритм генерации id и каждый вендор выбирает его по своему усмотрению. Составив базу отпечатков тегов различных почтовых серверов, можно точно отличить тот же postfix от exim, не послав жертве ни одного пакета!

Противодействие

Разумеется, существует множество разных способов защиты от fingerprinting. От сканирования nmap'ом могут помочь механизмы в OpenBSD PF (block from any os NMAP, scrub in all), как просто нормализующие трафик (а значит, маскирующие «особенности» систем, этот трафик генерирующих), так и определяющие сканирование и заставляющие nmap выдавать каждый раз разную чепуху. Сильно затрудняют анализ уже упомянутые мной blackholes во FreeBSD. Ведь, по сути, из всех тестов сканера только один эмулирует «нормальный» сеанс (SYN-пакет на открытый порт), все остальное – ошибочные пакеты, призванные исследовать реакцию системы на подобную «провокацию». Соответственно, нужно сделать систему как можно более «молчаливой».

Для Linux имеется проект IP Personality (http://ippersonality.sourceforge.net/) – патч к ядру, изменяющий поведение сетевого стека и позволяющий замаскировать систему под все, что не заблагорассудится, хоть под aix, хоть под приставку xbox.

Анализ типа сервиса может быть затруднен сменой баннеров, текстовых комментариев кодов ошибок. Никто не мешает тебе залезть в сорцы любимого SMTP-сервера и ручками поменять алгоритм генерации ID-тега :).

Мораль сей басни

Fingerprinting – чертовски полезная для взломщика технология, однако она служит не для атаки на сверхзащищенные системы, а является способом определения уязвимой машины в заданном диапазоне адресов. Не даром различные проявления этой технологии можно встретить в авторутерах, автоэксплоитах или в обычных (но надо признать, не очень простых) сканерах безопасности.

Статью Fyodor, переведенную на русский язык, можно найти по адресу http://www.insecure.org/nmap/nmap-fingerprinting-article-ru.html.

От сканирования nmap'ом могут помочь механизмы в OpenBSD PF, нормализующие трафик.

Анализ типа сервиса может быть затруднен сменой баннеров, текстовых комментариев и кодов ошибок.

Технология remote fingerprinting хорошо зарекомендовала себя при производстве авторутеров/автоэксплоитов. Подобным программам очень полезно бывает сначала проверить версию сервиса или ОС, а уж потом применять эксплоит.