Начало.
Как-то на HackZone я встретил заметочку о том, что взломан web-сервер фирмы IdSoftware с помощью стандартных примеров скриптов, идущих в поставке с WebSite'ом, - args.bat и uploader.exe. А так как в нашем университете довольно много www серверов на основе WebSite (ну если штук 5-6 это много), то я решил вплотную занятся ими 
Итак, взлом осуществляется через стандартные примеры, идущие в поставке с web-сервером, а так как люди еще не сильно задумываются о защите своего сайта, считая это не очень большой проблемой, и часто оставляют все на Авось, то просто ставят WebSite, ничего не предпринимая для его настройки и обеспечения достаточной защиты. Все пять найденных мной сайтов под управлением WebSite v1.1 имели лазейку, описанную ниже, которая обеспечивала почти полный доступ к машине, на которой они находились, в том числе и мой
Необходимое.
Как у нас ставят WebSite? Просто давят кнопку Install, и потом прога говорит, что web-сервер поставлен. Люди находят, где находится корень web-сайта, закачивают туда свою информацию, и все так и живет, пока не наступает время дельта Тэ (с) Zeus. Что же появляется в таком состоянии? По умолчанию отображается (мапится, mapping) куча ненужных для работы сервера каталогов /java/, /publish/, /wsdocs/, /cgi-dos/, /cgi-win/. Конечно, в какой-то момент времени они, возможно, и понадобятся, но вначале они просто не нужны. Это с одной стороны, с другой стороны создателям WebSite со всех сторон нужно показать возможности этого сервера, что они с успехом и делают, открывая потециальные дырки в защите web сайта и заполняя эти каталоги разнообразными примерами, так радующими глаз потенциального взломщика.
Сперва я поставил себе на машину WebSite v1.1f в дефолтовой конфигурации и приступил к исследованию его на дырки.
Задача перед нами стоит такая: закачать на ломаемый сервер какое-нибудь средство удаленного администрирования и управления типа ВО или NetBus и запустить его (я использовал по-быстрому найденный в нашей локалке NetBus v1.6 с именем файла серверной части Patch.exe).
Этап закачки для нас не представлял никакого интереса т.к. по умолчанию WebSite позволяет удаленно запустить /cgi-win/uploader.exe и закачать кому угодно что угодно. В принципе, так даже можно положить эту самую НТ: закачивать туда всякой фигни, пока место на диске не кончится. Скорей всего, тут ей кранты и придут - это если WebSite стоит на том же диске, где стоит система или валяется своп-файл (но я в этих вопросах не сильно силен, пусть меня поправят более знающие люди, да и речь сейчас не об этом).
Вторым этапом является выяснение месторасположения каталога с WebSite'ом. Это делается тоже отчень легко, просто удаленно запускаем файл /cgi-dos/ args.bat, на что нам в ответ приходит сообщение типа
Empty output from CGI program D:/WebSite/cgi-dos/args.bat
, что однозначно определяет каталог с WebSite'ом. Тогда отображаемый каталог /cgi-dos/ будет находится в каталоге D:/WebSite/cgi-dos/, а путь к файлу Patch.exe, который мы закачиваем будет D:/WebSite/UploadS/Patch.exe
Итак, момент к которому мы подошли - это исследование на предмет возможности запуска файла, который мы закачали. Почитывая разные статьи по этому поводу, например, выяснилось, что у web-сервера Apache есть уязвимость на счет тестовых скриптов /cgi-bin/test-cgi и /cgi-bin/nph-test-cgi, которые аналогичны присутствующему в WebSite примеру Args.bat. Эта уязвимость заключается в том, что возможна распечатка передаваемой строки в таком виде, в каком она присутствует, и это обычно делается строчкой скрипта
echo QUERY_STRING = $QUERY_STRING
т.е. если мы передаем строчку типа "> 1.bat", то по логике вещей строчка "QUERY_STRING =" будет перенаправлена в файл 1.bat, путь к этому файлу мы могли бы указать на каталог /cgi-bin/, он бы туда записался, и далее уже удаленно мы могли бы его запустить из этого каталога. В args.bat находится строчка
echo QUERY_STRING="%QUERY_STRING%" >> %of%
т.е. кто не слеп и видит, что строчка, передаваемая нами заключена в кавычки, и все, что мы надумали, просто-напросто обламывается. Обламывается-то обламывается, но все дело в том, что мы можем засылать специальные непечатные символы типа CR (код 0dh), LF( код 0ah). Улавливаете? Появление таких символов в командной строке приведет к переводу строки в скрипте и вполне возможно, что следущей строчкой вдруг ни с того ни с сего окажется наш файл лежащий в каталоге /uploads/ . Уф, такие мысли просто будоражат кровь!
Так, сейчас мы ее маленько остудим, рассмотрев немного теории, поясняющей как запускаются .bat скрипты на web сервере на основе WebSite.
При обработке bat-скрипта во временном каталоге WebSite /cgi-temp/ создаются 4 файла xxxxx.acc, xxxxx.bat, xxxxx.inp, xxxxx.out. Нам в глаза сразу бросается файл xxxxx.bat. Так, при удаленном запуске /cgi-dos/args.bat получается такой файл xxxxx.bat:
@ECHO OFF&&TITLE WebSite CGI
D:\WebSite\cgi-dos\args.bat < D:\WebSite\cgi-temp\xxxxx.inp > D:\WebSite\cgi-temp\xxxxx.out
если этому .bat файлу кинуть в командной строке аргументов, например, /cgi-dos/args.bat?africa.bat, то получим xxxxx.bat:
@ECHO OFF&&TITLE WebSite CGI
D:\WebSite\cgi-dos\args.bat africa.bat < D:\WebSite\cgi-temp\xxxxx.inp > D:\WebSite\cgi-temp\xxxxx.out
Кто знает, что такое перенаправление потока данных (значки ">" и "<"), сразу поймет, что здесь к чему. По-простому, WebSite создает временный xxxx.bat файл, результаты деятельности которого перенаправляются в файл xxxxx.out. Этот файл xxxxx.out отдается удаленному клиенту результатом работы скрипта, если в работе скрипта не произошло ошибки. Во временных файлах вместо символов xxxxx подставляется случайная последовательность символов.
Запускаем вот так /cgi-dos/args.bat?>d:/Website/cgi-shl/1.bat получаем xxxxx.bat:
@ECHO OFF&&TITLE WebSite CGI
D:\WebSite\cgi-dos\args.bat africa.bat ^>D:/WebSite/cgi-shl/1.bat < D:\WebSite\cgi-temp\xxxxx.inp > D:\WebSite\cgi-temp\xxxxx.out
Видите, как нехорошо поступил WebSite - перед символом перенаправления ">" поставил какую-то гадость "^", от которой всякое перенаправление перестает быть перенаправлением. Если немного помучится, то можно выяснить, что эта фигня ставится перед символами >,< и |. Кстати, если залезть внутрь исполняемого файла сервера httpd32.exe, то вы увидите как раз стоящие отдельной группой данные символы. Обломс!
Как я уже писал выше, мы можем в командную строку вставлять спецсимволы, делается это так %0a. "%" - символ, говорящий о том, что следующие за ним два символа являются шестнадцатиричным представлением передаваемого в командной строке символа.
Запускаем /cgi-dos/args.bat?%0d%0aafrica.bat. Получаем xxxxx.out:
@ECHO OFF&&TITLE WebSite CGI
D:\PROGRA~1\WebSite\cgi-dos\args.bat
africa.bat < D:\WebSite\cgi-temp\xxxxx.inp > D:\WebSite\cgi-temp\xxxxx.out
Вот тут я подумал что они попали , но жестоко обманулся! 
По моим мыслям, сначала управление передастся их батчику, а потом моему исполняемому файлу, который я закачал в /uploads/. Меня жестоко обманули, управление, переданное файлу args.bat, там и оставалось. Моему файлу africa.bat оставалось лишь смотреть, как управление было всего в одной строчке сверху его!
Cнова думаем! Вернемся к перенаправлению, если забивать много много перенаправлений типа ">", то вполне возможно, что в какой-то момент времени на каждый значок ">" не хватит значка "^", так как вполне возможно, что буфер у WebSite не резиновый. Стандартными средствами тут я уже обходится не мог, так как не мог ввести слишком много значков в строке адреса Internet Explorer'a, поэтому пришлось воспользоваться программой NetCat v1.10 for NT, ох и рульная же это вещица, при всем при том, что о большинстве функций я вообще не знаю, для чего они нужны. В моем случае она просто брала из файла запрос и отсылала его серверу.
nc.exe -v ИмяЛомаемогоСервера 80 < Zapros.txt
Zapros.txt:
GET /cgi-dos/args.bat?>>>>>>>>>>....>>>africa.bat
Вот такой файл, где значков ">" около 700 штук после запуска NetCat'a с такими параметрами у меня повесил WebSite Хорошенькая нашлась фича, и, главное, обнаружилась фича, что если число значков равно 512, то вместо строк в темповом батчике xxxxx.bat
@ECHO OFF&&TITLE WebSite CGI D:\PROGRA~1\WebSite\cgi-dos\args.bat?^>^>^>^>...^>^> africa.bat < D:\WebSite\cgi-temp\xxxxx.inp > D:\WebSite\cgi-temp\xxxxx.out
Получается файл xxxxx.bat:
@ECHO OFF&&TITLE WebSite CGI africa.bat^>^>^>
>^>^>>^>^>>^>^>^....^>^>^>>^>^>>^>^>^ D:\WebSite\cgi-temp\xxxxx.inp > D:\WebSite\cgi-temp\xxxx.out
Классное переполнение буфера получилось!!!!! Затем я после africa.bat поставил символы перевода строки 0dh,0ah (%0d%0a) и africa.bat поменял на regedit.exe, запустил NetCat, и что бы вы думали, у меня получилось? Угу, запустился regedit!!!!
Я еще немного потренировался, и выяснилось, что она не хочет, или не желает пускать програмки с длинными именами и с длинными путями к ним. Хорошо, что Website, где я его встречал, стоит прямо в корне, и доступ к каталогу /uploads/ получаем без проблем. И еще хорошо, что я начал с символа ">", если подставлять другие нормальные символы типа буковок или циферок, то WebSite на это никак не реагирует, просто не принимает их, если их довольно большое количество, и выдает ошибку, если они все поместились в буфер.
Ну, вот так я запустил на другой машинке NetBus, и дальше уже дело техники (почти).
Выкачиваем все нужное с Хакнутой машины.
Закачиваем в каталог /cgi-shl/ с помощью NetBus'а еще одну копию серверной части этого самого NetBus'a под каким-нибудь дурацким именем. Я, например, закачиваю под именем win-c-example.exe т.к. он в этом каталоге уже есть, только соответственно старый файл нужно убить.
Убиваем логи сервера access.log, error.log, upload.log. Вы думаете их просто убить? =) Фиг там, WebSite держит их открытыми, тут-то нам и пригодится умение ронять WebSite обнаруженный в начале нашего исследования. т.е. роняем WebSite, и только затем удаляем все логи.
Нехорошо, если после нас в каталоге /uploads/ останется бяка в виде серверной части NetBus'a, ее нужно убить, но увы, она держится системой открытой поэтому мы просто перезагружаем всю машинку с WebSite'ом, перед этим сказав NetBus'у "Remove Server". Вот эта часть плана у меня не очень чисто проходила, в NetBuse я использовал и Reboot и Shutdown, и все равно удаленный сервер сам по себе не поднимался, не знаю почему, а пробовать на своей машине было влом. Тем не менее когда-нибудь ту машинку поднимали, считая что Винда это Сакс, и он сам может из-за пылинки вылететь в даун. Когда сервер снова поднялся, быстренько из /cgi-shl/ запускаем снова Netbus и чистим /uploads/ (Позже я выяснил, что NetBus копирует себя в системный каталог операционнки, и оттуда загружается в следующий раз, поэтому описанные действия немного неточны, и необходимо просто перезагрузить сервер)
Фу! Ну вот и все, дальше все ясненько, можно ломать дальше, отслеживая пароль Administrator'a т.к. обычно на тех тачках, где весит WebSite, находится и PDC (Primary Domain Controler). Можно, балуясь NetBus'ом, создать ситуацию, когда Administrator будет вынужден подойти к своему детищу и набрать заветное слово, которое нам и покажет Netbus Короче, все остальное лирика.
Был произведен "дружественный взлом" двух серверов, выкачана с них нужная информация, ну и затем сообщено о существующей дырке. В WebSite v2.xxx эта дыра закрыта, так как отсутствует каталог /cgi-dos, но присутствуют другие файлы типа guestbook, которая позволяет писать тэги, плюс присутствуют сырцы этих файлов, что меня очень радует и дает возможность заниматься таким интересным делом!
Никаких заключительных слов говорить не буду, читайте статью DiGGertaL SpOOn'а, там как раз есть то, что можно делать после взлома и заключительные слова.
"Все это мое последнее слово" Дельфин