Как у нас ставят WebSite? Просто давят кнопку Install, и потом прога говорит, что web-сервер поставлен. Люди находят, где находится корень web-сайта, закачивают туда свою информацию, и все так и живет, пока не наступает время “дельта Тэ”.

Что же появляется в таком состоянии? По умолчанию отображается (мапится, mapping) куча ненужных для работы сервера каталогов /java/, /publish/, /wsdocs/, /cgi-dos/, /cgi-win/. Конечно, в какой-то момент времени они, возможно, и понадобятся, но вначале они просто не нужны. Это с одной стороны, с другой стороны создателям WebSite со всех сторон нужно показать возможности этого сервера, что они с успехом и делают, открывая потенциальные дырки в защите web-сайта и заполняя эти каталоги разнообразными примерами, так радующими глаз потенциального взломщика.

Поставим на машину WebSite v1.1f в дефолтовой конфигурации иприступим к исследованию его на дырки.

Задача перед нами стоит такая: закачать на ломаемый сервер какое-нибудь средство удаленного администрирования и управления, типа ВО или NetBus, и запустить его. Этап закачки не представляет никакого интереса, т.к. по умолчанию WebSite позволяет удаленно запустить /cgi-win/uploader.exe и закачать кому угодно что угодно.

Вторым этапом является выяснение месторасположения каталога с 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/, он бы туда записался, и далее уже удаленно мы могли бы его запустить из этого каталога.

Мы можем засылать специальные непечатные символы типа 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.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.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.out

Видите, как нехорошо поступил WebSite — перед символом перенаправления > поставил какую-то гадость ^, от которой всякое перенаправление перестает быть перенаправлением.

Если забивать много много перенаправлений типа >, то вполне возможно, что в какой-то момент времени на каждый значок > не хватит значка ^, так как вполне возможно, что буфер у WebSite не резиновый.