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

Идея удаленно определять версию ОС или запущенного на хосте сервиса не нова. Все знают, что популярный сканер 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 toxa@19X.XX.1.20X

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 xxx@xxx.ru 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, не послав жертве ни одного пакета!