Все, сказанное выше, справедливо и для удаления групп, которое теоретически осуществляется командой “rmgroup ИмяГрупы”, а практически автору не удалось найти ни одного сервера, допускающего ее выполнение неавторизованным пользователем.
Но существуют и непривилегированные команды, доступные всем пользователям. Несмотря на «несолидное» название, среди них порой попадаются на удивление любопытные экземпляры. Например, команда “SENDSYS”, выдает список всех «соседей» сервера, вместе со схемой пересылки конференций. Эта информация дает возможность минимальными усилиями построить топологию сети Usenet, и позволяет сосредоточить поиск бесплатных серверов лишь в перспективных направлениях (т.е. тестировать крупнейшие узлы, с множеством нисходящих подписчиков).
Может вызвать удивление, что команда “SENDSYS” относиться к числу непривилегированных, но такой уж устав Usenet. В первом абзаце тринадцатой страницы RFC-1036 содержатся следующие строки «This information is considered public information, and it is a requirement of membership in USENET that this information be provided on request…»
Впрочем, RFC - не уголовный кодекс и придерживаться его никто не обязан, как часто и встречается на практике.
Другой командой, способной обойти запрет на отправку сообщений, считается “IHAVE” (с одноименным управляющим сообщением “ihave”). Обычно она используется для синхронизации сообщений, - с ее помощью один узел сообщает другому идентификаторы имеющихся у сообщений и в случае отсутствия идентичной корреспонденции сервер выражает готовность принять недостающее сообщение у соседа.
Этот обмен является частью протокола «IHAVE-SENDME» и разрабатывался исключительно для взаимодействия узлов, но не пользователей. Теоретически ничто не мешает злоумышленнику прикинуться сервером и сообщить о наличие у него нового сообщения. Таким образом, можно было бы получить доступ даже к тем группам, постинг в которые при нормальном ходе вещей считается невозможным.
Практически же, подобная атака неосуществима. Примеры реакций некоторых серверов на команду «IHAVE» приведены ниже:
· 200 news.medlux.ru InterNetNews NNRP server INN 1.5.1 17-Dec-1996 ready (posting ok).
· IHAVE «kpnc@post.me»
· 480 Transfer permission denied
· 201 nn02.news.ocn.ad.jp InterNetNews NNRP server INN 2.2 21-Jan-1999 ready (no posting).
· IHAVE «kpnc@astronomy.net»
· 480 Authentication required for command
· 200 NNTP Service Microsoft® Internet Services 5.5 Version: 5.5.1877.19 Posting Allowed
· IHAVE «1976@ngc.org»
· 502 Access Denied.
Оказывается, вопреки ранее установленным стандартам, протокол «IHAVE-SENDME» успел обзавестись средствами авторизации и фильтрами IP-адресов отправителей. Ныне отправлять сообщения на сервер могут лишь те узлы, адреса которых «знакомы» получателю.
Впрочем, отсюда еще не вытекает невозможность успешной атаки. (Например, возможна фальсификация IP-адресов отправителя). Но NNTP-протокол разрабатывался в первую очередь вовсе не из соображений безопасности, поэтому мелкие недоработки достаточно безобидны и вполне простительны. Напротив, программные реализации могут содержать ошибки, позволяющие захватить контроль над удаленной системой.
Воистину легендарной стала ошибка, обнаруженная в INN 1.4-INN 1.5, обнаруженная 7 июля 1995 года. Она упоминается буквально во всех источниках, так или иначе связанных с безопасностью.
Сервер INN 1.4 содержал серьезную ошибку, позволяющую выполнить любую команду на удаленной машине. Для этого ее достаточно было поместить в заголовок управляющего сообщения. Дыра появлялась вне зависимости от того, были ли разрешены управляющие сообщения или нет. Причина заключалась в том, что сервер обрабатывал содержимое поля “Control” с помощью команды “eval” оболочки «sh», таким образом, злоумышленник получал возможность запустить любой процесс через Exec, под привилегиями root.
Удивительно, но ошибка сохранилась и в следующей, версии программы, хотя к тому времени уже стала широко известна. Позже обнаружились и другие ляпы, о которых можно узнать подробнее на www.securityfocus.com
Ничем не лучше оказался «Microsoft Exchange Server», уязвимый против атак «отказ в обслуживании». К чести Microsoft она всегда оперативно выкладывает «заплатки», в которых, впрочем, устраняя одни ошибки, нередко вносит новые.
В Microsoft Exchange Server версиях 5.х, была допущена ошибка в реализации обработчика команд “AUTH” (“XAUTH”) и “EHLO”, связанная с переполнением буфера. При этом появлялась следующее сообщение:
msexcimc.exe - Application Error
The instruction at "0x77f7d514" reference memory at "0x711cc771".
The memory could not be written.
После чего сервер прекращал свою работу (операционная система при этом не зависала).
Протокол HTTP
O В этой главе:
O Сеанс работы с HTTP-сервером
O Удаленное выполнение программ
O Модификация и удаление ресурсов на сервере
O Механизмы аутентификации
O Интерфейс CGI
O История возникновения HTML
Бесспорно, HTTP (Hyper Text Transfer Protocol) относится к числу наиболее популярных протоколов и с каждым годом все сильнее вытесняет даже таких корифеев, как FTP, NNTP, POP3, SMTP, IMAP4. Современные пользователи скачивают файлы, щелкая мышкой по ссылке, участвуют в конференциях, организованных на WEB-серверах, передают и принимают почту с помощью браузера. Словом, с точки зрения обывателя, Internet и WWW - слова-синонимы.
Создается впечатление, что протокол HTTP, реализующий все перечисленные выше возможности, должен быть невероятно сложным для понимания, но это совсем не так! Минимальное взаимодействие с WEB-сервером обеспечивается даже при знании всего лишь одной команды!
Невероятно? Вовсе нет, - круг задач, возложенных на HTTP, ограничивается поддержкой передачей данных от сервера к клиенту и в редких случаях наоборот. Дальнейшая обработка информации не входит в его компетенцию, и этим занимается специализированное программное обеспечение.
В базовые задачи WEB-сервера входит поддержка удаленного выполнения программ, и передача файлов в формате MIME.
Клиент же занимается отображением полученной информации (гипертекст, графика, анимация) и выполнением переданного ему программного кода (Java, Visual Basic Script).
В главах «Атака на WEB-сервер» и «Атака на WEB-клиента» будет показано, как и почему такая схема стала уязвима против атак.
Для подключения к HTTP-серверу необходимо установить с ним TCP-соединение по восьмидесятому порту (если не оговорено обратное) [251].
Появление курсора в окне telnet-клиента [252] означает готовность к приему команд от пользователя. Взаимодействие осуществляется по схеме «запрос-ответ», подробное описание которой содержится в RFC-1945 и в RFC-2068, а в этой главе будут рассмотрены лишь основные моменты, впрочем, вполне достаточные для полноценного взаимодействия в WEB-сервером.
Структура запроса выглядит следующим образом:
Если не указывать версию HTTP, ответ будет возращен в спецификации HTTP 0.9, которую обязан поддерживать каждый клиент