ПРОБЛЕМА. Исследование: новый анализ червя Code Red II
Данное исследование проведено компанией CNET New.com (© 2001). В июле 2001 г. червь под названием Code Red атаковал и заразил тысячи серверов Windows 2000. Несколькими неделями спустя, в августе 2001 г., мутировавшая форма червя под названием Code Red II использовала тот же механизм, что и Code Red, для заражения уязвимых серверов IIS, на которых не была устранена прямая опасность переполнения буфера в idq.dll, или не были удалены отображения сценариев ISS ISAPI.
Совет. О том, как устранить уязвимое место, связанное с возможностью переполнения буфера, вы узнаете в лекции 3.
За исключением механизма переполнения буфера для выполнения кода червя на уязвимом сервере IIS червь Code Red II коренным образом отличался от исходных вариантов червя Code Red CRv1 и CRv2.
Червь Code Red II имел несколько опасных особенностей. Самой серьезной из них являлось то, что червь создавал "черный ход" посредством размещения "троянского коня" в файле CMD.EXE на зараженном сервере, что делало систему абсолютно открытой для любого хакера.
Червь копировал файл %windir%\CMD.EXE в следующие места:
- c:\inetpub\scripts\root.exe;
- c:\progra~1\common~1\system\MSADC\root.exe;
- d:\inetpub\scripts\root.exe;
- d:\progra~1\common~1\system\MSADC\root.exe.
"Черный ход" позволял хакеру выполнять любые команды на взломанном сервере.
Кроме того, червь размещал на системе-жертве второго "троянского коня", являвшегося модифицированной версией файла explorer.exe (Диспетчер рабочего стола), который давал удаленному хакеру беспрепятственный доступ к корневым каталогам C: и D: после следующего входа пользователя в систему (если в системе не было устранено уязвимое место "Relative Shell Path"); это стало возможным благодаря способу, которым Windows по умолчанию осуществляет поиск исполняемых файлов.
Совет. В лекции 3 будет рассказываться о том, как устранить уязвимое место "Relative Shell Path", связанное с относительным путем оболочки.
По прошествии времени распространения инфекции система принудительно перезагружалась.
При перезагрузке из памяти удалялся резидентный червь, а "черные ходы" и explorer.exe оставались на месте.
При первом попадании червя на компьютер-жертву и его выполнении осуществлялась проверка заражения данного сервера, в этом случае червь отключал сам себя. После создания "троянских коней" в виде файлов explorer.exe процессы создания файлов приостанавливались. Каждые 10 минут они повторялись с выполнением всех своих процедур, поэтому даже если администратор обнаруживал в реестре параметры, открывающие доступ к C: и D: и удалял их, через несколько минут "троянский конь" прописывал настройки заново.
Червь выбирал жертву, автоматически сканируя системы и определяя, устранены ли на них уязвимые места, связанные с файлом idq.dll и с отображениями сценариев ISS ISAPI, которые использовались для переполнения буфера. После успешного подключения к цели подпроцесс червя отгружал весь код червя на удаленный компьютер, ожидал подтверждения, после чего продолжал поиск и заражение других узлов.