Geum.ru

«Техника сетевых атак»

Вид материалаКраткое содержание

Содержание


Рисунок 21 Так выглядит главная станица сервера после ее модификации
История о Забывчивости и Извращениях, или как маленький локальный Баг изменил ход дела
Рисунок 22 Microsoft Web Publishing поддерживает метод POST необходимый для «заливки» документов на сервер
Method Not Allowed
HTTP Error 403
HTTP Error 401
Врезка «информация»
Врезка «алгоритм кодировки base64»
Рисунок 23 Настойка Outlock Express для пересылки писем в кодировке Base64
Get / http/1.0
Врезка «замечание»
Рисунок 024 Передача параметров методом GET
Врезка «информация»
Врезка «информация»
Http/1.1 200 ok
Подобный материал:
1   ...   31   32   33   34   35   36   37   38   ...   51




  • Здесь был Вася...





  • Если операция прошла успешно, главная страница в браузере Internet Explorer будет выглядеть так:




    Рисунок 21 Так выглядит главная станица сервера после ее модификации



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

    "И взбрело мне (по закрепившейся привычке) поглядеть степень защищенности и (самое главное) степень тупости админа. Для этого я стал юзать (что думаете???) свой любимый Нетскап 3.01 (Браузер Netscape Navigator поддерживает метод PUT, в отличие от Internet Explorer – К.К). Стал лазить по директориям и обнаружил очень странную для сегодняшнего дня вещь, а именно директории /scripts и /cgi-bin оказались открытыми"

    « История о Забывчивости и Извращениях, или как маленький локальный Баг изменил ход дела» Story by DiGGertaL SpOOn (Оригинал статьи находится по адресу ссылка скрыта).

    Дальше статья повествует, как наивный чукотский «вьюноша» манипулировал всеми «хакерскими» утилитами по очереди, ломясь в широко открытую дверь. Чтобы повторить его «подвиг» вовсе не обязательно устанавливать на своей машине Netscape Navigator. Можно воспользоваться, например, приложением «Microsoft Web Publishing», которое поддерживает закачку файлов на сервер по HTTP протоколу всеми доступными способами:




    Рисунок 22 Microsoft Web Publishing поддерживает метод POST необходимый для «заливки» документов на сервер



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

    Ниже приведены протоколы трех последовательных попыток подключения к следующим серверам: ссылка скрыта, ссылка скрыта и 2.222.

    • PUT /index.phpl HTTP/1.0

    • HTTP/1.1 405 Method Not Allowed
    • Date: Sat, 15 Apr 2000 21:50:26 GMT
    • Server: Apache/1.2.6
    • Allow: GET, HEAD, OPTIONS, TRACE
    • Connection: close
    • Content-Type: text/html



    • <b>405 Method Not Allowed</b>


    • Method Not Allowed


    • The requested method PUT is not allowed for the URL /index.phpl.





    • PUT /Index.phpl HTTP/1.0

    • HTTP/1.1 403 Access Forbidden
    • Server: Microsoft-IIS/4.0
    • Date: Sat, 15 Apr 2000 22:04:25 GMT
    • Content-Length: 495
    • Content-Type: text/html



    • Error 403.3


    • HTTP Error 403



    • 403.3 Forbidden: Write Access Forbidden


    • This error can be caused if you attempt to upload to, or modify a file in, a
    • directory that does not allow Write access.


    • Please contact the Web server's administrator if the problem persists.




    • PUT /Index.php HTTP/1.0

    • HTTP/1.1 401 Access Denied
    • WWW-Authenticate: NTLM
    • WWW-Authenticate: Basic realm="195.161.42.222"
    • Content-Length: 644
    • Content-Type: text/html



    • Error 401.2

    • HTTP Error 401



    • 401.2 Unauthorized: Logon Faile d due to server configuration

    • This error indicates that the credentials passed to the server do not match the
    • credentials required to log on to the server. This is usually caused by not s
    • ending the proper WWW-Authenticate header field.


    • Please contact the Web server's administrator to verify that you have permiss
    • ion to access to requested resource.



    Первые два случая говорят о правильной конфигурации сервера (с точки зрения политики безопасности), но факт авторизации сам по себе еще не свидетельствует о защищенности (быть может, используется простой пароль, наподобие «guest»).


    Механизмы аутентификации HTTP серверов довольно многочисленны, поэтому ниже будет описан лишь один, наиболее распространенный, из них. Всю остальную информацию можно почерпнуть из технической документации RFC 2068 и RFC 2069.

    Начиная со спецификации HTTP 1.0, код ошибки “401” зарезервирован за «Access Denied, need authenticate261». Именно его возвратил сервер в последнем примере. Ниже заголовок ответа сервера приводится еще раз:

    • HTTP/1.1 401 Access Denied
    • WWW-Authenticate: Basic realm="195.161.42.222"
    • Content-Length: 644
    • Content-Type: text/html


    Выделенная жирным шрифтом строка «Basic» указывает на требуемый метод аутентификации, а “realm” содержит имя области аутентификации. На сервере может существовать несколько независимых друг от друга зон, каждая со своей схемой доступа. В приведенном случае, очевидно, единственная область аутентификации распространяется на весь сервер.

    Чтобы получить доступ к любому ресурсу, расположенному на 195.161.42.222, необходимо сообщить имя пользователя и пароль, задаваемые полем “Authorization” в заголовке запроса, и закодированные согласно правилам выбранного метода аутентификации.

    В простейшем случае, когда не требуется прибегать к серьезным защитным механизмам, используют метод basic, передающий открытый, незашифрованный пароль в кодировке base64. При использовании клиентом метода basic появляется возможность «подглядывания» пароля злоумышленником, сумевшим перехватить сетевой трафик262. Довольно часто администраторы игнорируют такую угрозу и разрешают метод based для доступа к критической к разглашению информации263, что категорически не рекомендуется в RFC 2068.

    Врезка «информация»


    «The most serious flaw in Basic authentication is that it results in the essentially clear text transmission of the user's password over the physical network. It is this problem which Digest Authentication attempts to address.

    Because Basic authentication involves the clear text transmission of passwords it SHOULD never be used (without enhancements) to protect sensitive or valuable information.»

    RFC-2068, раздел 15.1, страница 140.

    Врезка «алгоритм кодировки base64»


    Битовый поток разбивается на двадцати четырех битовые сегменты, делящиеся на четыре части по 6 бит (26 == 64, отсюда и название), каждая из которых содержит один символ, кодируемый в соответствии с особой таблицей, состоящей из читабельных кодов ASCII.


    Выполнить вручную перекодировку строки пароля в base64 формат довольно-таки затруднительно, но у пользователей Windows всегда под рукой средство, автоматизирующее эту задачу. Речь идет о приложении “Outlook Express”. Достаточно настроить его надлежащим образом (в меню «Сервис» выбрать пункт «Параметры», перейти к закладке «Отправка сообщений» кликнуть по кнопке «Настойка текста»; в открывшемся диалоговом окне установить кодировку Base64) и послать письмо самому себе – оно будет автоматически перекодировано.




    Рисунок 23 Настойка Outlock Express для пересылки писем в кодировке Base64



    При этом строка “KPNC:MyGoodPassword”264 будет выглядеть следующим образом (в меню «Файл» выбрать «Свойства», перейти к закладке «Подробности», кликнуть по кнопке «Исходный текст сообщения»):

    • S1BOQzpNeUdvb2RQYXNzd29yZ


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

    • GET / HTTP/1.0
    • Authorization: Basic S1BOQzpNeUdvb2RQYXNzd29yZ



    Если пароль введен правильно, то сервер вернет запрошенный ресурс. В противном случае появится сообщение об ошибке.

    Врезка «замечание»


    В Internet-магазинах и аналогичных системах, предъявляющих повышенное требование к безопасности, широко используется шифрование данных на уровне транспортного протокола TCP.

    Популярный механизм SSL (Secure Sockets Layer) представляет собой самостоятельный протокол, применяющийся для передачи зашифрованного пароля и пользовательских данных, поверх которого могут работать как HTTP, так FTP, SMTP и другие протоколы.

    Реализации SSL поддерживают множество криптоалгоритмов, таких как RSA, DES, MD5, выбираемых в зависимости от ценности и рода передаваемой информации. К сожалению, ранние версии ограничивались ключами небольшой длины, но с развитием Internet – торговли это было исправлено265.

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


    Метод POST, аналогично PUT, предназначен для передачи данных от клиента на сервер. Однако они не сохраняются в виде файла, а передаются скрипту параметрами командой строки. С первого взгляда непонятно, какими соображениями руководствовались разработчики при введении нового метода. Ведь с этой задачей неплохо справляется и GET! Пример, приведенный ниже, доказывает справедливость такого утверждения:



    • Click



    Рисунок 024 показывает, что параметры, передаваемые скрипту методом GET, отображаются в адресной строке браузера и доступны для изучения всем желающим. А это нехорошо с точки зрения политики безопасности.




    Рисунок 024 Передача параметров методом GET



    Результат работы POST незаметен для пользователя, поэтому он хорошо справляется с передачей конфиденциальных данных. Но прежде чем продолжить повествование, необходимо ознакомиться формой представления параметров.

    Строго говоря, способ представления и отделения параметров друг от друга может варьироваться от разработчика к разработчику. Строка, переданная скрипту, независимо от формы записи, может быть целиком получена с помощью функции ARGV, и в этом смысле она ничем не отличается от привычной командной строки консольных приложений для MS-DOS и Windows. Тем не менее, разработчики стараются придерживаться определенных соглашений. Обычно строка параметров представляет собой совокупность лексем, разделенных символами “&”. Каждая лексема состоит из имени параметра и его значения, разделенных знаком равенства. Все нечитабельные символы заменяются знаком “%” и последующим за ним шестнадцатеричным значением символа. От имени ресурса строка параметров отделяется вопросительным знаком. Сказанное поясняет следующий пример:

    • lightning.prohosting.com/~kpnc/cgi-bin/post.pl?user=kpnc&pass=saltmine


    Все, находящееся слева вопросительного знака, то есть “lightning.prohosting.com/~kpnc/cgi/-bin/post.pl” называется именем ресурса (сокращенно URL или URN – Uniform Resource Name). URL состоит из имени хоста (в даннос случае “lightning.prohosting.com”), пути (“/~kpnc/cgi-bin/”) и имени файла (“post.pl”).

    За именем файла следует строка параметров, образованная из двух лексем – “user=kpnc” и “pass=saltmine”. Порядок лексем не играет никакой роли, и скрипт будет работать ничуть не хуже, если их поменять местами.

    Каждая лексема состоит из имени параметра («user», «pass») и его значения («kpnc» и «saltmine» соответственно). Символ пробела в значениях параметра недопустим, поэтому, если потребовалось бы «saltmine» написать раздельно266, то это выглядело бы так “salt%20mine”.

    Врезка «информация»


    Любопытная особенность связана с возможностью записи одного и того же IP адреса огромным множеством способов. Например, его можно представить в шестнадцатеричном виде, воспользовавшись префиксом ‘0x’, тогда «209.90.125.196» (адрес узла lightning.prohosting.com) будет выглядеть как «0xD1.0x5A.0x7D.0xC4»267. Если число начинается с нуля, то оно трактуется как восьмеричное, и тот же адрес может быть записан как «0321.0132.0175.0304». Наконец, символ ‘b’ в окончании числа указывает на двоичную форму записи268.

    Очевидно, описанные выше способы можно комбинировать друг с другом, получая в результате этого, например, «0xD1.0132.125.0xC4» (первое и последние числа шестнадцатеричные, второе слева восьмеричное, и оставшееся – десятичное).

    Вообще же, с точки зрения операционной системы любой IP адрес это одно 32 битное целое, поэтому некоторые приложения269 позволяют опустить точку-разделитель. Однако для этого необходимо предварительно перевести адрес в шестнадцатеричную форму записи. Это легко понять, так как «0xD1.0x5A.0x7D.0xC4» и «0xD15A7DC4» взаимно эквиваленты между собой. Но ничто не мешает полученный результат перевести в любую другую, например десятичную («3512368580») или восьмеричную («032126476704») нотацию270.

    Кроме этого, допустимо вместо символа использовать его ASCII код, предваренный знаком процента. Так, например, выражение «%32%30%39%2E%39%30%2E%31%32%35%2E%31%39%36» эквивалентно адресу «209.90.125.196»!

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

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

    Врезка «информация»


    Одним из способов аутентификации может быть передача имени пользователя и пароля в строке запроса следующим образом: @host/path/file

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


    Очевидно, следует избегать появления пароля в адресной строке браузера. С этой точки зрения очень удобен метод POST, передающий значения всех параметров в теле запроса. Однако, скрипту, анализирующему данные, совершенно все равно, каким способом те были посланы – он не отличает POST от GET. Пример, приведенный ниже, доказывает это утверждение:

    • GET /~kpnc/cgi-bin/post.pl?user=kpnc&pass=saltmine HTTP/1.0

    • HTTP/1.1 200 OK
    • Date: Sun, 16 Apr 2000 17:01:10 GMT
    • Server: Apache/1.3.6 (Unix)
    • Connection: close
    • Content-Type: text/html