Дополнение. Поиск общедоступных NNTP-серверов

 

Ø В этой главе:

Ø Сканирование портов

Ø Поиск серверов, путем изучения заголовков сообщений

Ø Описание программы News Hunter

 

Среди сотен тысяч узлов сети существует огромное количество общедоступных серверов, явно или неявно предоставляющих пользователям те или иные ресурсы. Мелкие корпорации, научные и исследовательские учреждения обычно не склонны обременять свои NNTP‑сервера защитой и порой их ресурсами могут безболезненно пользоваться все остальные узлы сети…

 

Врезка «для начинающих»

Случайно натолкнутся на общедоступный NNTP-сервер маловероятно, а найти его с помощью служб, наподобие «Апорта» или «Altavista» очень трудно. Запрос “NNTP + free” выдаст длинный список бывших когда-то бесплатными серверов, большинство из которых уже успели прекратить свое существование или сменить политику и ограничить доступ.

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

 

Простейший способ поиска NNTP‑серверов заключается в сканирование портов. Суть его заключается в следующем: выбирают некий (возможно взятый наугад) IP‑адрес, например «195.161.42.149» и пытаются установить с ним TCP‑соединение по сто девятнадцатому порту. Успешность операции указывает на наличие NNTP‑сервера на данном узле. Если же сервер не отсутствует или не функционален, соединение установить не удастся. В случае успешно установленного соединения пытаются убедиться в бесплатности службы, иначе (сервер не установлен или не бесплатен) выбирают другой IP‑адрес, и так до тех пор, пока не кончится терпение или не отыщется требуемый ресурс. Как правило, при сканировании IP адреса перебираются один за другим с убыванием или возрастанием на единицу за каждый шаг.

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

Легко посчитать, сколько займет исследование даже небольшой подсети. В главе «Как устроен сканер портов»[235] рассказывается о некоторых способах, позволяющих ускорить процесс сканирования, но какие бы оптимизирующие алгоритмы не применялись, (например, попытки асинхронного соединения с несколькими узлами одновременно), эффективность такого подхода не может быть значительно увеличена в силу огромного числа существующих IP‑адресов.

Сканирование пригодно для исследования локальных сети различных компаний, но найти с его помощью хороший NNTP‑сервер в Internet очень трудно, поскольку таких серверов относительно немного, и все они достаточно равномерно распределены по пространству IP‑адресов.

 

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

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

В следующем примере в качестве объекта сканирования[236] выступает крупного поставщика сетевых услуг (в том числе и телеконференций) Демос, публичный web-сайт которого так называется www.demos.su, (IP‑адрес равен 194.87.0.48[237])

Используя любой сканер, (например, «SuperScan», расположенный на страничке http://members.home.com/rkeir/software.html) можно исследовать узкий диапазон адресов 194.87.0.1 – 194.87.0.254 всего лишь за десяток – другой минут.

В результате этой операции обнаруживается, что Демос имеет множество промежуточных SMTP и NNTP серверов, открытых для прямого доступа! Например, таких как:

 

nntp://relay2.demos.su

nntp://news.ru[238]

nntp://jubo.demos.su

nntp://new2.demos.su

nntp://nntp.demos.su

 

Фрагмент протокола сканирования находится на диске под имением /LOG/demos/txt. Он типичен для крупного провайдера, имеющего в своем распоряжении десятки серверов.

 

Другой способ поиска бесплатных NNTP‑серверов заключается в изучении заголовков сообщений, полученных с любого NNTP‑сервера. В процессе путешествия по сети, сообщения проходят через один или несколько транзитных серверов, каждый из которых включает в заголовок свой адрес.

В определенном роде NNTP‑сервер это гигантский почтовый ящик, заполненный корреспонденцией со всех сторон света. Среди транзитных серверов и серверов отправителя сообщения часто попадаются и такие, которые предоставляют бесплатный доступ всем пользователям.

Полный путь, проделанный сообщением, содержится в поле “Path”, а сервер отправителя в поле “NNTP-Posting Host”. В примере, приведенном ниже, показаны заголовки двух сообщений: (поля “Path” и “NNTP-Posting Host” выделены жирным шрифтом):

 

· Path: news.medlux.ru!Melt.RU!carrier.kiev.ua!news.kharkiv.net!useua!not-for-mail

· From: Nadezda Alexsandrovna <[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.

· Date: Thu, 6 Apr 2000 05:01:15 +0300

· Lines: 16

· Distribution: world

· Message-ID: <[email protected]>

· Reply-To: [email protected]

· NNTP-Posting-Host: ums.online.kharkov.com

· NNTP-Posting-Date: 6 Apr 2000 02:02:11 GMT

· Xref: news.medlux.ru medlux.trade.optika:904

 

 

· From: [email protected]

· Subject: ammivit

· Reply-To: [email protected]

· Message-ID: <[email protected]>

· Newsgroups:ural.commerce

· Date: Mon, 27 Mar 2000 04:48:14 +0400

· Lines: 25

· Path: news.medlux.ru!mailserver.corvis.ru

· NNTP-Posting-Host: t1-55.sitek.net 212.34.32.118

· Xref: news.medlux.ru relcom.medicine.blood-service:2982

 

Поразительно, но эти два сообщения открывают семь восемь NNTP‑серверов (и это еще не самый лучший результат)! Все они, перечислены ниже:

 

· nntp://news.medlux.ru (бесплатный)

· nntp://Melt.RU (хост не найден)

· nntp://carrier.kiev.ua (бесплатный)

· nntp://news.kharkiv.net (приватный)

· nntp://ums.online.kharkov.com (хост не найден)

· nntp://mailserver.corvis.ru (бесплатный)

· nntp://t1-55.sitek.net (хост не найден)

 

И хотя часть узлов по непонятой причине не отвечает[239], результатами «улова» трудно оставаться недовольным. Анализом заголовков всего двух сообщений найдено три бесплатных сервера, разрешающих постинг.

А если проанализировать все сообщения, находящиеся на каждом из этих серверов, и все сообщения на каждом из вновь найденных серверов, подобным рекурсивным спуском можно найти едва ли не все NNTP‑сервера, существующие в сети!

Узкое место такой операции – пропускная способность канала, соединяющего ищущего с Internet. Получать гигабайты сообщений через модемную линию нереально. Поэтому, эту задачу лучше переложить на плечи автономного скрипта, работающего на узле с быстрым каналом, или различными способами оптимизировать алгоритм (так, например, ни к чему получать от одного и того же адресата более одного сообщения, а количество уникальных отправителей в сети велико, но конечно)[240].

Впрочем, глубокое сканирование сети бессмысленно. Достаточно найти один (максимум два-три) быстрых и надежных NNTP‑сервера, которые ввиду своей распространенности попадаются очень быстро.

На этом секреты поиска бесплатных NNTP‑серверов заканчиваются. Конечно, описанные выше операции вручную выполнять было бы затруднительно, но они легко поддаются автоматизации и уже реализованы в десятках различных программ. Большой популярностью пользуется упомянутый выше «News Hunter 4.0» (http://www.slip.net/~rain/nh/). Помимо всего прочего он умеет стоить удобные отчеты и измерять скорость соединения с каждым узлом, - это помогает выбрать из них самый лучший.

К сожалению, даже последняя на момент написания книги, четвертая версия, не снабжена сканером IP‑адресов и, по крайней мере, хотя бы один NTTP‑сервер пользователь должен найти самостоятельно.

Для этого пригодиться методика, описанная в начале главы. Достаточно найти любой сервер, предоставляющий доступ хотя бы на чтение к одной-двум конференциям. Анализируя заголовки сообщений, «News Hunter» найдет все остальные.

 

 

Рисунок 14 Результат работы News Hunter

 

Однако, используя найденный таким образом сервер, приходится всегда быть готовым к тому, что в любой момент политика администрирования может измениться, вследствие чего свободный доступ на некоторое время (или навсегда) закроют. Единственный способ этого избежать – пользоваться платными, надежными ресурсами.

 

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

Весьма удобным сервисом является www.MailAndNews.com, позволяющий отправлять письма в конференции… прямо со своего почтового ящика. Помимо быстроты и надежности поддерживается протокол IMAP4, однако, предоставим слово владельцам сервера:

You can use this service to create a free e-mail account that will be accessible from any web browser, anywhere in the world. You will also have access to newsgroups and the ability to check your mail from any touch tone phone, plus a variety of wireless devices. MailandNews.com also works with other Internet e-mail clients, allowing you to access your new mailbox using Outlook Express, Netscape Messenger, Eudora, Pegasus Mail, or Infinite Technologies ExpressIT! 2000.

 

Атака на NNTP-сервер.

 

Ø В этой главе:

Ø Как отправить анонимное сообщение?

Ø Как обойти фильтрацию IP адресов?

Ø Как отправить сообщение в конференцию с ведущим?

Ø Как можно использовать управляющие сообщения?

Ø Как получить контроль над удаленной машиной?

 

 

При описании NNTP‑протокола упоминалось, что большинство серверов определяют IP‑адрес отправителя сообщения и включают его в заголовок. Чем это чревато? Выставляя свои сетевые координаты на всеобщее обозрение, отправитель серьезно рискует, подвергнуться атаке со стороны злоумышленника, решившего испытать на нем новый эксплоит. Помимо этого, нетрудно установить какому провайдеру принадлежит тот или иной IP‑адрес, и выяснить, по крайней мере, географическое происхождение отправителя сообщения. Отсюда уже рукой подать до установления личности жертвы. Грубо говоря, резкой критикой в адрес предмета чужого обожания, вы рискуете, однажды выйдя из подъезда, схлопотать по морде[241].

Поэтому, с точки зрения личной безопасности, IP‑адрес лучше скрыть. Этого можно достичь, используя Proxy‑сервер, или скрипт, исполняющийся на удаленном узле. В написании такого скрипта нет ничего сложного, – достаточно вспомнить команды NNTP‑протокола и последовательно передать их серверу, через TCP‑соединение. На языке Perl листинг не займет и десятка строк. Простейший пример находится на прилагаемом к книге диске, в файле “/SRC/nntp_post.pl”. Он предназначен для запуска через браузер и должен быть помещен на любой сервер, поддерживающий CGI.

Результат работы скрипта показан ниже:

 

 

Рисунок 16 Результат работы скрипта, создающего новое сообщение

 

Заголовок сообщения, отправленного с помощью скрипта, должен выглядеть приблизительно следующим образом:

 

· Path: news.medlux.ru!not-for-mail

· From: <[email protected]>

· Newsgroups: medlux.test

· Subject: helo

· Date: 11 Apr 2000 10:33:45 GMT

· Organization: Medlux InterNetNews site, Moscow, Russia

· Lines: 1

· Message-ID: <[email protected]>

· NNTP-Posting-Host: spider.softclub.net

· Xref: news.medlux.ru medlux.test:548

·

· Helo!

 

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

Такой прием часто используют не только для сокрытия собственного адреса, но и в других целях. Например, некоторые NNTP‑сервера доступны лишь из доменов *.NET, но не *.COM и тем более *.RU

 

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

Обидно, конечно, но ни для кого не секрет, что посетители “from Russia Federation” часто считаются людьми второго сорта. Порой им закрывают доступ, отказываются предоставлять бесплатный хостинг, и вообще стараются по возможности избегать.

Поэтому, некоторые ресурсы становятся доступными лишь с использованием иноземных Proxy-серверов или скриптов, расположенных в соответствующих местах.

 

Так, отечественный сервер news://news1.demos.su/ доступен исключительно из-под домена *.net[242], а при попытке подсоединиться к нему любым другим пользователям он сообщает, разрывая соединение:

 

· 502 You have no permission to talk. Goodbye

 

Другой возможной причиной отказа в обслуживании становится невозможность определения доменного имени клиента по его IP адресу (Reverse Lockup). Это зависит исключительно от настоек DNS‑сервера провайдера клиента, некоторые из которых не поддерживают такой возможности.

В этом случае, сообщения большинства NNTP‑серверов будут выглядеть приблизительно следующим образом:

 

· 502 You have no permission to talk, (reverse dns disabled, see nodns in dnews.conf) {209.143.154.93}, Goodbye

 

Словом, существует множество причин для использования Proxy‑серверов или любых других способов введения NNTP‑сервера в заблуждение. Однако списки общедоступных Proxy есть не только у пользователей, но и администраторов, которые порой включат их в «черный список». Напротив, использование скриптов не получило массового распространения, поэтому, только параноические администраторы запрещают доступ со всех серверов, предоставляющих бесплатный хостинг.

Следующий пример демонстрирует подключение к узлу nntp://news1.demos.su, путем использования слегка модифицированного файла nntp_post.pl (модификация заключается в замене адрес сервера, и добавления команды “LIST” для выдачи списка доступных групп).

Спустя секунду-другую после запуска скрипта в окне браузера должен появится текст, приблизительно следующего содержания:

 

· 201 demos2 InterNetNews NNRP server INN 1.7.2 14-Dec-1997 (DEMOS revision) ready (no posting).

· >LIST

· 215 Newsgroups in form "group high low flags". demos.local.ads 0000000003 0000000004 m.

 

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

В качестве альтернативы можно попробовать поместить исполняемый код не на сервер, а локальную машину, владелец которой заведомо (или потенциально) имеет доступ к необходимому ресурсу.

 

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

Среди тысяч вирусов существует, по крайней мере, два, пользующихся для своих нужд ресурсами NNTP. Это печально известные «Worm.Happy» (Internet – червь) и «Win32.Parvo» (файловый).

 

Однако установить соединение с NNTP‑сервером это только половина проблемы. Гораздо важнее получить возможность создания собственных сообщений. Большинство конференций (особенно из группы Fido7) запрещают прямой постинг, и такие группы отмечаются флагом “m” (от английского moderator – ведущий конференции).

Попытка проигнорировать это ограничение ни к чему не приводит. Даже если север подтвердит успешность отправки, сообщение никуда не будет отправлено. Но если добавить в заголовок сообщения поле “Approved” с указанием адреса модератора (или адреса отправителя), такое сообщение, скорее всего, будет воспринято, как правильное, и без проблем добавится в конференцию.

Протокол, приведенный ниже (на диске, прилагаем к книге, он находится в файле “/LOG.nntp_post.log”), демонстрирует использование поля “Approved” для отправки писем в конференцию, доступ к которой обычным способом невозможен.

 

·; Устанавливается соединение с сервером news.medlux.ru по 119 порту

· 200 news.medlux.ru InterNetNews NNRP server INN 1.5.1 17-Dec-1996 ready (posting ok).

·; Получение списка доступных конференций на сервере

·; и выбор любой из них, помечанной флагом m

· list

· 215 Newsgroups in form "group high low flags".

· medlux.dept.docs 0000000173 0000000174 m

· medlux.dept.lic 0000000086 0000000087 m

· medlux.dept.qual.doc 0000000150 0000000151 m

· medlux.doc.acc 0000001621 0000001622 m

· medlux.doc.apt 0000000320 0000000321 m

· medlux.doc.ministry 0000000808 0000000809 m

· medlux.doc.mos 0000001722 0000001723 m

· medlux.doc.rus 0000003030 0000003030 m

· medlux.doc.spb 0000000367 0000000368 m

· medlux.drugs.reg 0000000041 0000000042 m

· medlux.drugs.safety 0000000142 0000000143 m

· medlux.fido.su.medic 0000036131 0000036110 y

· medlux.firmhist 0000000616 0000000600 y

· medlux.health 0000001748 0000001625 y

· medlux.journal.top 0000000306 0000000307 m

· medlux.journal.vit 0000000113 0000000114 m

· medlux.medsci.anes 0000000465 0000000442 y

· medlux.medsci.cardiol 0000000572 0000000528 y

· medlux.medsci.dent 0000000441 0000000406 y

· medlux.medsci.dermatol 0000000488 0000000443 y

· medlux.medsci.diag 0000001059 0000001004 y

· medlux.medsci.endocrin 0000000495 0000000448 y

· medlux.medsci.gastroent 0000000483 0000000427 y

· medlux.medsci.gyn 0000000683 0000000636 y

· medlux.medsci.hematol 0000000400 0000000358 y

· medlux.medsci.immunol 0000000436 0000000389 y

· medlux.medsci.inform 0000001250 0000001176 y

· medlux.medsci.neurol 0000001093 0000000989 y

· medlux.medsci.oncology 0000000652 0000000596 y

· medlux.medsci.ophthalm 0000000476 0000000436 y

· medlux.medsci.pediatr 0000000686 0000000650 y

· medlux.medsci.pharmacol 0000000693 0000000629 y

· medlux.medsci.pulmonol 0000000396 0000000359 y

· medlux.medsci.san-hyg 0000000400 0000000367 y

· medlux.medsci.surg 0000000674 0000000637 y

· medlux.medsci.talk 0000000961 0000000906 y

· medlux.medsci.therapy 0000000465 0000000429 y

· medlux.medsci.urol 0000000491 0000000456 y

· medlux.medsci.z 0000000654 0000000606 y

· medlux.mfy.exhibitions 0000000159 0000000160 m

· medlux.mfy.expo 0000000047 0000000048 m

· medlux.mfy.public 0000000096 0000000097 m

· medlux.misc.advert 0000002695 0000002689 y

· medlux.misc.gossips 0000000470 0000000470 y

· medlux.misc.jobs 0000003661 0000003620 y

· medlux.newspaper.szs 0000000470 0000000471 m

· medlux.newusers 0000000377 0000000375 y

· medlux.postmasters 0000000137 0000000138 m

· medlux.request 0000000450 0000000448 y

· medlux.trade.cosm 0000001681 0000001675 y

· medlux.trade.dent 0000000850 0000000847 y

· medlux.trade.drugs 0000006884 0000006879 y

· medlux.trade.herb 0000001340 0000001329 y

· medlux.trade.lab 0000001762 0000001753 y

· medlux.trade.mtechn 0000004666 0000004654 y

· medlux.trade.optika 0000000904 0000000900 y

· medlux.trade.rubber 0000002936 0000002928 y

· medlux.medsci.contents 0000000310 0000000272 y

· medlux.journal.cg 0000000040 0000000041 m

· medlux.medsci.homoeopathy 0000001365 0000001253 y

· medlux.fido.ru.medic.profy 0000008681 0000008678 y

· medlux.test 0000000546 0000000543 y

· medlux.journal.umo.science 0000000002 0000000003 m

· medlux.journal.umo.z 0000000002 0000000003 m

· medlux.fido.ru.baby.medic 0000010291 0000010233 y

· medlux.trade.service 0000000722 0000000708 y

· medlux.medsci.orthopaedics 0000000245 0000000215 y

· medlux.medsci.cardiovascular 0000000119 0000000089 y

·.

· group medlux.doc.rus

· 211 0 3030 3030 medlux.doc.rus

·; В этой группе нет ни одного сообщения!

· next

· 421 No next to retrieve.

·; Действительно, здесь ничего нет!

·; Попытка создания нового сообщения

· post

· 340 Ok

·; Разрешение отправки? Хм, странно…

· Newsgroups:medlux.doc.rus

· From:[email protected]

· Subject:try

·

· Hello,Sailors!

·.

· 240 Article posted

·; Неужели сообщение было отправлено?!

· group medlux.doc.rus

· 211 0 3030 3030 medlux.doc.rus

·; Опаньки! Содержимое группы ничуть не обновилось. Сообщение не было отправлено

·; Попытка отправить сообщение с использованием поля Approved.

· post

· 340 Ok

· Newsgroups:medlux.doc.rus

· From:[email protected]

· Subject:Test

· Approved:[email protected]

·

· Helo,World!

·.

· 240 Article posted

·; Проверка наличия сообщения на сервере

· group medlux.doc.rus

· 211 1 3030 3030 medlux.doc.rus

·; На сервере появилось новое сообщение!

·; Проверка – то ли это сообщение, что было отправлено

· article

· 220 3030 <[email protected]> article

· Path: news.medlux.ru!not-for-mail

· From: <[email protected]>

· Newsgroups: medlux.doc.rus

· Subject: Test

· Date: 8 Apr 2000 12:24:27 GMT

· Organization: Medlux InterNetNews site, Moscow, Russia

· Lines: 1

· Approved: [email protected]

· Message-ID: <[email protected]>

· NNTP-Posting-Host: ppp-18.krintel.ru

· Xref: news.medlux.ru medlux.doc.rus:3030

·

· Hello, World!

·.

·; Без комментариев J

· next

· 421 No next to retrieve.

·; Завершение сеанса

· quit

· 205.

 

Это сработало! Сообщение мгновенно появилось на сервере, и спустя некоторое время оказалось разослано всем остальным[243]. К сожалению, популярное клиентское программное обеспечение не поддерживает возможности добавления поля “Approved”, и возникает необходимость создания собственного инструмента (не работать же, в самом деле, всю жизнь в окне telnet‑клиента).

На диске, прилагаемом к книге, содержится демонстрационный пример “/SRC/nntp/htm”, который позволяет отправлять сообщения в модерируемые конференции. Его возможности наглядно демонстрирует следующий эксперимент. Если выбрать группу «с ведущим»[244], (например, medlux.doc.rus на сервере nntp://news.medlux.ru) и попробовать отправить свое сообщение с помощью «Outlook Express», то оно с завидным упорством откажется добавляться в конференцию. Но, если использовать скрипт “NNTP Test Post”, то сообщение незамедлительно появится в группе!

 

 

Рисунок 017 Демонстрация отправки сообщения в конференцию с ведущим

 

А заголовок отправленного сообщения должен выглядеть приблизительно так (поле “Approved” выделено жирным шрифтом, именно с его помощью удалось обойти ограничение сервера):

 

· Path: news.medlux.ru!not-for-mail

· From: [email protected]

· Newsgroups: medlux.doc.rus

· Subject: Test posing

· Date: 11 Apr 2000 11:06:28 GMT

· Organization: Medlux InterNetNews site, Moscow, Russia

· Lines: 1

· Approved: [email protected]

· Message-ID: <[email protected]>

· NNTP-Posting-Host: spider.softclub.net

· Xref: news.medlux.ru medlux.doc.rus:3032

·

· Hello,Sailor!

 

Неплохо бы теперь удалить тестовые сообщения из группы[245]. Как это можно сделать? Какие вообще существуют способы управления сервером? В далекое доисторическое время, когда сеть была доступна ограниченному кругу лиц, и еще никто всерьез не задумывался о безопасности, была предложена концепция управляющих сообщений. В общих чертах суть ее заключалось в том, что если в послании содержалось некое ключевое слово, сервер интерпретировал следующий за ним текст как команды.

Эта методика завоевала большую популярность у разработчиков в виду привлекающей простоты реализации и дожила в неизменном виде до наших дней. Большинство NNTP‑серверов допускают удаленное администрирование, не требуя для этого никаких прав.

Управляющие сообщения отличаются от всех остальных наличием поля “Control” в заголовке или ключевым словом “cmsg” в поле “Subject”, оставшаяся часть которого интерпретируется как команды. Поэтому, нет нужды в специализированном программном обеспечении для администрирования сервера, вполне сойдет ваш любимый клиент.

 

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

Когда-то все происходило несколько иначе. Управляющими считались поля “Subject”, в сообщениях, адресованных группе “ all.all.ctl ”. Для обеспечения совместимости многие серверы до сих пор поддерживают такое поведение, хотя описанная концепция устарела не на один ледниковый период.

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

 

Запретить управляющие сообщения администратор не может, потому что они используются для организации взаимодействия между NNTP‑серверами. Впрочем, можно настроить систему безопасности так, чтобы потенциально «опасные» команды требовали аутентификации пользователя и были доступны лишь с соответствующими привилегиями доступа. Но в большинстве случаев установленную защиту можно с легкостью обойти, используя простейшие приемы подделки полей заголовка.

Для удаления сообщения можно воспользоваться командой “cancel”, указав уникальный идентификатор (“Message-Id”) удаляемого послания. Отправлять такую команду может только администратор сервера или автор сообщения, то есть поля “From” в удаляемом и управляющем посланиях должны совпадать[246].

Для того чтобы узнать идентификатор сообщения, достаточно воспользоваться командой HEAD. Если удаляемое сообщение текущее, то это может выглядеть, например, так:

 

· HEAD

· 220 3031 <[email protected]> article

· Path: news.medlux.ru!not-for-mail

· From: [email protected]

· Newsgroups: medlux.doc.rus

· Subject: Test

· Date: 8 Apr 2000 12:35:48 GMT

· Organization: Medlux InterNetNews site, Moscow, Russia

· Lines: 1

· Approved: [email protected]

· Message-ID: <[email protected]>

· NNTP-Posting-Host: ppp-18.krintel.ru

· Xref: news.medlux.ru medlux.doc.rus:3031

·.

 

Чтобы иметь возможность убедиться в успешности выполнения операции, необходимо воспользоваться командой 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 она всегда оперативно выкладывает «заплатки», в которых, впрочем, устраняя одни ошибки, нередко вносит новые.

 

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

В 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

 

Ø В этой главе:

Ø Сеанс работы с HTTP-сервером

Ø Удаленное выполнение программ

Ø Модификация и удаление ресурсов на сервере

Ø Механизмы аутентификации

Ø Интерфейс CGI

Ø История возникновения 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].

 

 

 

Рисунок 18 Диалог «подключение»

 

Появление курсора в окне telnet‑клиента[252] означает готовность к приему команд от пользователя. Взаимодействие осуществляется по схеме «запрос - ответ», подробное описание которой содержится в RFC‑1945 и в RFC‑2068, а в этой главе будут рассмотрены лишь основные моменты, впрочем, вполне достаточные для полноценного взаимодействия в WEB-сервером.

Структура запроса выглядит следующим образом:

 

· «Метод» «Запрашиваемый Ресурс» «Версия HTTP»

· Поле 1: значение A

· Поле 2: значение B

·...

· <CRLF>