Червь Nimda отмечает 25 лет. Какой ущерб он нанес?
В сентябре 2001 года в мире появился продвинутый червь Nimda, который сегодня помнят как один из вирусов, использовавших IIS. У него было и больше способов распространения, и не все из них можно было залатать. Сегодня у Nimda не было бы шансов на такой успех.
Nimda действительно распространялся через IIS, но помимо этого использовал и ресурсы общего доступа к файлам Windows (SMB/NetBIOS). Он атаковал не только серверы (в основном незащищённые — уязвимость, которой он пользовался, исправили годом раньше), но и рабочие станции с Windows 95/98. Однако чтобы распространяться по ним, нужно было, чтобы что‑то автоматически запускало код. В их случае виновником оказался Internet Explorer.
Защиты: есть, но бессмысленны
Проблема с Internet Explorer вытекает из недостатков его главной силы: он был платформой, способной запускать внешний код в разных формах и встраиваться в документы и приложения. IE рендерил веб‑страницы, но также отображал представления папок и редакторы сообщений электронной почты. В зависимости от контекста выполняемый код имел разные привилегии. Если код был из интернета — его считали небезопасным. Если локальный — он получал полные права. Эта концепция известна как Зоны безопасности, и её отголоски остаются в Windows до сих пор.
Вопреки злым языкам, зоны безопасности появились в IE не поздно, после скандалов. Это довольно ранняя функция, которая, к сожалению, работала плохо. Она защищала в интернете, но имела много «слепых зон». Иногда было достаточно выдать себя за кого‑то безопасного, чтобы IE поверил. Большее же зло таилось в локальной зоне. В неё относились скрипты WSH, приложения HTA, представления папок HTT и… почта! Поскольку почту загружали на машину, её считали локальной, не так ли? Это предположение приводило к тому, что IE присваивал локальную зону скриптам внутри писем. Хотя они должны были служить для анимации на шаблонах, использовав полный движок IE, они могли даже загружать скомпилированный код ActiveX.
Достаточно было получить письмо с Nimdą и один раз кликнуть для просмотра — и компьютер начинал рассылать червя дальше. Вирус также добавлял себя во множество мест в системе, которые позволяли загружать его после перезагрузки. А когда он встречал жёсткие диски, расшаренные без пароля — он делал то же самое на удалённых машинах. Если пользователь не получил Nimda по почте, ничего страшного. Инфицированный IIS вместе с HTML‑документом подавал файл EML (то есть офлайн‑сообщение), который открывался Outlook’ом, тот считал его локальным и… происходило то же самое. Достаточно было зайти на инфицированную страницу через Internet Explorer.
Исправил ли Microsoft дырявые Зоны безопасности и IIS? Не пришлось. IIS уже давно был заплатан, а Internet Explorer 5.5 получил Service Pack летом 2001 года. Обновления давно устранли проблему, но… на многих компьютерах они не устанавливались автоматически. Это позволило червю распространяться несмотря на патчи. А какой ущерб нанес Nimda? Помимо генерации огромного сетевого трафика и ломки настроек системы в целях облегчения распространения — немного. Это, впрочем, серьёзно: хотя файлы не повреждались и не шифровались, сам факт «засевания» вируса по миру сильно подрывал доверие. Кроме того, некоторые варианты Nimda приклеивались к EXE‑файлам — по‑старинке, как старые вирусы.
Будущее безопаснее?
Остаётся вопрос, свободен ли нынешний дизайн Windows от подобных ошибок. В большинстве случаев да, если речь о «текущих» зонах безопасности. Здесь сильно помог переход с Internet Explorer на Edge и исчезновение «традиционных» почтовых клиентов. Носители проблемы, вроде встроенного MSHTML, стали неиспользуемыми; WSH и HTA отключены/недоступны и подлежат удалению; представлений папок HTT нет уже много лет, но…
Остался PowerShell. Его практически нельзя выключить (в отличие от WSH). Можно запретить запуск неподписанных скриптов, но можно запустить PowerShell.exe с параметром «Unrestricted», а затем вставить весь скрипт в кавычки и выполнить inline. Правда, сейчас ничего не делает таких вещей автоматически (даже макросы Office по умолчанию отключены), но появились волны фальшивых сайтов «скопируй этот код и вставь в окно Выполнить, чтобы подтвердить, что ты человек». Microsoft не хочет добавлять простые переключатели для блокировки PowerShell, утверждая, что он работает как надо. Нас ждут ещё несколько лет присутствия этой проблемы.
Автор: администратор Windows Server и RHEL. Занимается кибербезопасностью в одной из компаний списка Fortune 500. Временно преподаватель в вузе. Проявляет нездоровый интерес к философии, политике и разрушению циркадного ритма. Одноядерный.
