Краткое содержание «Техника сетевых атак»
жүктеу/скачать 3.83 Mb.
|
- Бұл бет үшін навигация:
- Рисунок 16 Результат работы скрипта, создающего новое сообщение
- Рисунок 017 Демонстрация отправки сообщения в конференцию с ведущим
Атака на NNTP-сервер.
При описании NNTP протокола упоминалось, что большинство серверов определяют IP адрес отправителя сообщения и включают его в заголовок. Чем это чревато? Выставляя свои сетевые координаты на всеобщее обозрение, отправитель серьезно рискует, подвергнуться атаке со стороны злоумышленника, решившего испытать на нем новый эксплоит. Помимо этого, нетрудно установить какому провайдеру принадлежит тот или иной IP адрес, и выяснить, по крайней мере, географическое происхождение отправителя сообщения. Отсюда уже рукой подать до установления личности жертвы. Грубо говоря, резкой критикой в адрес предмета чужого обожания, вы рискуете, однажды выйдя из подъезда, схлопотать по морде241. Поэтому, с точки зрения личной безопасности, IP адрес лучше скрыть. Этого можно достичь, используя Proxy сервер, или скрипт, исполняющийся на удаленном узле. В написании такого скрипта нет ничего сложного, – достаточно вспомнить команды NNTP протокола и последовательно передать их серверу, через TCP соединение. На языке Perl листинг не займет и десятка строк. Простейший пример находится на прилагаемом к книге диске, в файле “/SRC/nntp_post.pl”. Он предназначен для запуска через браузер и должен быть помещен на любой сервер, поддерживающий CGI. Результат работы скрипта показан ниже: 
Рисунок 16 Результат работы скрипта, создающего новое сообщениеЗаголовок сообщения, отправленного с помощью скрипта, должен выглядеть приблизительно следующим образом:
Выделенная жирным шрифтом строка говорит о том, что отправитель сумел остаться анонимом! И в заголовке сообщения не содержится никакой информации, способной пролить свет на его происхождение, за исключением сведений оставленных им самостоятельно. Такой прием часто используют не только для сокрытия собственного адреса, но и в других целях. Например, некоторые NNTP сервера доступны лишь из доменов *.NET, но не *.COM и тем более *.RU
Врезка «замечание»Обидно, конечно, но ни для кого не секрет, что посетители “from Russia Federation” часто считаются людьми второго сорта. Порой им закрывают доступ, отказываются предоставлять бесплатный хостинг, и вообще стараются по возможности избегать. Поэтому, некоторые ресурсы становятся доступными лишь с использованием иноземных Proxy-серверов или скриптов, расположенных в соответствующих местах. Так, отечественный сервер news://news1.demos.su/ доступен исключительно из-под домена *.net242, а при попытке подсоединиться к нему любым другим пользователям он сообщает, разрывая соединение:
Другой возможной причиной отказа в обслуживании становится невозможность определения доменного имени клиента по его IP адресу (Reverse Lockup). Это зависит исключительно от настоек DNS сервера провайдера клиента, некоторые из которых не поддерживают такой возможности. В этом случае, сообщения большинства NNTP серверов будут выглядеть приблизительно следующим образом:
Словом, существует множество причин для использования Proxy серверов или любых других способов введения NNTP сервера в заблуждение. Однако списки общедоступных Proxy есть не только у пользователей, но и администраторов, которые порой включат их в «черный список». Напротив, использование скриптов не получило массового распространения, поэтому, только параноические администраторы запрещают доступ со всех серверов, предоставляющих бесплатный хостинг. Следующий пример демонстрирует подключение к узлу nntp://news1.demos.su, путем использования слегка модифицированного файла nntp_post.pl (модификация заключается в замене адрес сервера, и добавления команды “LIST” для выдачи списка доступных групп). Спустя секунду-другую после запуска скрипта в окне браузера должен появится текст, приблизительно следующего содержания:
В момент написания этой главы, оказалась доступна всего лишь одна конференция, но это ничуть не уменьшает значимости того факта, что удалось «достучаться» до сервера, доступ к которому при нормальном ходе вещей оставался невозможен. В качестве альтернативы можно попробовать поместить исполняемый код не на сервер, а локальную машину, владелец которой заведомо (или потенциально) имеет доступ к необходимому ресурсу.
Врезка «информация»Среди тысяч вирусов существует, по крайней мере, два, пользующихся для своих нужд ресурсами NNTP. Это печально известные «Worm.Happy» (Internet – червь) и «Win32.Parvo» (файловый). Однако установить соединение с NNTP сервером это только половина проблемы. Гораздо важнее получить возможность создания собственных сообщений. Большинство конференций (особенно из группы Fido7) запрещают прямой постинг, и такие группы отмечаются флагом “m” (от английского moderator – ведущий конференции). Попытка проигнорировать это ограничение ни к чему не приводит. Даже если север подтвердит успешность отправки, сообщение никуда не будет отправлено. Но если добавить в заголовок сообщения поле “Approved” с указанием адреса модератора (или адреса отправителя), такое сообщение, скорее всего, будет воспринято, как правильное, и без проблем добавится в конференцию. Протокол, приведенный ниже (на диске, прилагаем к книге, он находится в файле “/LOG.nntp_post.log”), демонстрирует использование поля “Approved” для отправки писем в конференцию, доступ к которой обычным способом невозможен.
Это сработало! Сообщение мгновенно появилось на сервере, и спустя некоторое время оказалось разослано всем остальным243. К сожалению, популярное клиентское программное обеспечение не поддерживает возможности добавления поля “Approved”, и возникает необходимость создания собственного инструмента (не работать же, в самом деле, всю жизнь в окне telnet клиента). На диске, прилагаемом к книге, содержится демонстрационный пример “/SRC/nntp/htm”, который позволяет отправлять сообщения в модерируемые конференции. Его возможности наглядно демонстрирует следующий эксперимент. Если выбрать группу «с ведущим»244, (например, medlux.doc.rus на сервере nntp://news.medlux.ru) и попробовать отправить свое сообщение с помощью «Outlook Express», то оно с завидным упорством откажется добавляться в конференцию. Но, если использовать скрипт “NNTP Test Post”, то сообщение незамедлительно появится в группе!
А заголовок отправленного сообщения должен выглядеть приблизительно так (поле “Approved” выделено жирным шрифтом, именно с его помощью удалось обойти ограничение сервера):
Неплохо бы теперь удалить тестовые сообщения из группы245. Как это можно сделать? Какие вообще существуют способы управления сервером? В далекое доисторическое время, когда сеть была доступна ограниченному кругу лиц, и еще никто всерьез не задумывался о безопасности, была предложена концепция управляющих сообщений. В общих чертах суть ее заключалось в том, что если в послании содержалось некое ключевое слово, сервер интерпретировал следующий за ним текст как команды. Эта методика завоевала большую популярность у разработчиков в виду привлекающей простоты реализации и дожила в неизменном виде до наших дней. Большинство NNTP серверов допускают удаленное администрирование, не требуя для этого никаких прав. Управляющие сообщения отличаются от всех остальных наличием поля “Control” в заголовке или ключевым словом “cmsg” в поле “Subject”, оставшаяся часть которого интерпретируется как команды. Поэтому, нет нужды в специализированном программном обеспечении для администрирования сервера, вполне сойдет ваш любимый клиент. Врезка «информация»Когда-то все происходило несколько иначе. Управляющими считались поля “Subject”, в сообщениях, адресованных группе “all.all.ctl”. Для обеспечения совместимости многие серверы до сих пор поддерживают такое поведение, хотя описанная концепция устарела не на один ледниковый период. Забавно, что в попытках защитить свой сервер и установить фильтры для управляющих сообщений многие администраторы забывают об этой маленькой документированной (плохо, но документированной) особенности. Запретить управляющие сообщения администратор не может, потому что они используются для организации взаимодействия между NNTP серверами. Впрочем, можно настроить систему безопасности так, чтобы потенциально «опасные» команды требовали аутентификации пользователя и были доступны лишь с соответствующими привилегиями доступа. Но в большинстве случаев установленную защиту можно с легкостью обойти, используя простейшие приемы подделки полей заголовка. Для удаления сообщения можно воспользоваться командой “cancel”, указав уникальный идентификатор (“Message-Id”) удаляемого послания. Отправлять такую команду может только администратор сервера или автор сообщения, то есть поля “From” в удаляемом и управляющем посланиях должны совпадать246. Для того чтобы узнать идентификатор сообщения, достаточно воспользоваться командой HEAD. Если удаляемое сообщение текущее, то это может выглядеть, например, так:
Чтобы иметь возможность убедиться в успешности выполнения операции, необходимо воспользоваться командой GROUP, запомнив число сообщений в группе до попытки удаления корреспонденции.
Аналогичным образом можно воспользоваться служебным полем “Control”, тогда заголовок будет выглядеть так:
Поле “Subject” должно присутствовать и в том и другом случае, иначе сервер не отправит сообщение. Если удаление прошло успешно, результат работы команды “GROUP” должен выглядеть приблизительно так:
Количество сообщений уменьшилось на единицу! Следовательно, одно из них было только что удалено. Впрочем, на локальных дисках подписчиков не произошло никаких изменений247, точно как и на всех серверах, уже успевших получить это сообщение. Врезка «замечание»Пользоваться управляющими сообщениями следует крайне осторожно. При возникновении ошибок обработки, сообщение об ошибке возвращается не отправителю, а администратору системы, последующие действия которого предугадать нетрудно. Впрочем, экая невидаль удалить собственное послание! Вот если бы было можно то же проделывать и с чужой корреспонденцией. Но почему бы нет? Достаточно подставить фиктивный адрес в поле “From” в заголовке сообщения. Эксперимент, приведенный ниже, демонстрирует удаление чужого сообщения с сервера:
В заголовке сообщения присутствуют два поля “From” и “Reply To”. В зависимости от настроек сервера он может проверять либо только первое из них, либо и то, и другое сразу. Врезка «информация»Стандарт предписывает сличать поля “From” и “Sender” (если есть) и ничего не говорит обо всех остальных. Поэтому различные разработчики могут реализовывать это по-разному. Например, можно отправить сообщение следующего содержания, в котором присутствует лишь поле “From”.
Таким же точно образом можно удалить содержимое всех конференций, достаточно воспользоваться несложным скриптом, по понятным причинам не прилагаемым к этой книге. Врезка «замечание»К сожалению, это действительно очень простой скрипт, который в состоянии написать даже начинающий программист. Хотелось бы, что бы владельцы NNTP-серверов серьезнее относились к вопросам безопасности и защиты информации. Гораздо надежнее защита от несанкционированного создания и удаления конференций. Когда-то, давным-давно, на заре существования Internet, любой пользователь мог создать собственную группу, или удалить чужую250. Для создания новой конференции было достаточно воспользоваться управляющей командой «newgroup ИмяГруппы», отослав ее на «all.all.ctl». Сегодня ситуация несколько изменилась. Только редкий сервер разрешит рядовому пользователю подобные операции, и, кроме того, куда отправлять сообщение? Единого мнения на этот счет никого нет. Например, на nntp://mailserver.corvis.ru существуют специальные группы, находящиеся в самом начале списка, выдаваемого командой LIST.
Но не стоит обольщаться, обнаружив флаг “y”, разрешающий постинг. При попытке отправить управляющее сообщение, сервер потребует авторизации, попросив ввести имя и пароль администратора. Бессмысленно пытаться выяснить их перебором. При первой же ошибке владелец сервера получит уведомление об атаке. Все, сказанное выше, справедливо и для удаления групп, которое теоретически осуществляется командой “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» приведены ниже:
Оказывается, вопреки ранее установленным стандартам, протокол «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. После чего сервер прекращал свою работу (операционная система при этом не зависала). жүктеу/скачать 3.83 Mb. Достарыңызбен бөлісу:
|
