Microsoft Way

Conficker.A-E или зачем нам фаервол

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

1. Срочно установить на все компьютеры в сети брандмауэр приложений от независимого разработчика. Это хоть и сама по себе странная идея, но в ней что-то есть, особенно, если хорошо известно, какие приложения должны иметь права на сетевое взаимодействие.
   Сложность заключается в том, что среднестатистический системный администратор представляет из себя несколько не специалиста по сетевому взаимодействию и еще неизвестно, чьи действия приведут к более длительному простою предприятия 😉 Встроенный же во все современные ОС брандмауер вполне достаточен для корпоративной среды. Да, разумеется, его тоже необходимо адекватно настроить. Но, благо, сделать это можно через групповые политики.
2. Запретить работу службы SERVER на всех рабочих станциях пользователей. Эта идея тоже сначала кажется далеко не самой плохой. Вот только необходимо понимать, что с запретом этой службы, пропадет всякая возможность удаленного управления рабочими станциями.
   И в сети, где есть более 100 рабочих станций, я бы на такую экзотику решился только при условии острого желания физических нагрузок и полного отсутствия серьезной работы.

Но адекватно настроенного брандмауера недостаточно. Необходимо также понимать, как именно происходит сетевое взаимодействие и что, образно говоря, крепкие ворота с надежными замками совершенно бесполезны, если рядом забыли построить сам забор.
Дело вот в чем: для управления рабочей станцией в правилах ее фаервола неприменно должно быть исключение. Это может быть исключение для конкретных, заведомо безопасных адресов серверов (или рабочих станций администратора), единственно имеющих право RPC доступа к управляемой станции. Кстати, для последних версий настольной и серверной ОС исключение может более гибко фильтроваться механизмом RPC Firewall Filters. Дело в том, что до этого момента правила фаервола применялись одинаково ко всем сетевым интерфейсам рабочей станции. Теперь многие вещи стали проще, но это не имеет отношения к рассматриваемой сейчас проблеме.
Но если есть калитка, в нее можно войти. И зараженный сервер не будет иметь ни малейших проблем в доступе к любой из рабочих станций. Как, впрочем, для любой рабочей станции доступ по RPC не может быть закрыт на подавляющем большинстве серверов.

Давайте вспомним методы распространения Conficker:
1. Уязвимость в сервисе SERVER (SVCHOST.EXE).
2. Автозапуск на сменных носителях.
3. Попытка подбора паролей администратора. Стоп! А о чем здесь сказано?

А вот о чем: при заражении, червь ищет все существующие на рабочей станции профили пользователей и с найденными именами пользователей пытается получить доступ к другим рабочим станциям сети. То есть, если на рабочую станцию когда-либо заходил пользователь, учетная запись которого в данный момент имеет администраторские права в домене, то нам остается только надеяться на то, что пароль этой учетной записи не содержится во встроенном словаре червя. Или на то, что в домене хотя бы настроена автоблокировка учетных записей из-за многократного ввода неверного пароля.
Да, я совершенно забыл упомянуть об этой проблеме в предыдущей статье о Conficker. Но жизнь показала, что…уж воистину, от самого себя человека не спасти 😉 Впрочем, о проблеме лишних полномочий я уже писал здесь: «и всем полные права в домене».

Кстати говоря, на данный момент Conficker действует лишь перебором по словарю. И это, вероятно, спасло от горечи поражения уже многих и многих. Поскольку червь при заражении системы внедряется в процесс, исполняемый от имени SYSTEM, для него не было бы никаких проблем получить доступ к LM хэшу паролей всех профилей, сохраненных на рабочей станции. Отчего-то очень редко встречаются случаи, когда администратор принудительно отключает этот убийственный для безопасности функционал. Отчего убийственный, я уже писал здесь: «скромный червь, ставший администратором».

А, впрочем, нет. Зачем было бы делать операцию дважды, если ее можно не делать вообще. Получив доступ к хэшу пароля, совершенно нет необходимости в его расшифровывании. Необходимо просто провести сессию авторизации с соседними рабочими станциями. Для успешной NTLMSSP сессии ведь нужен только хэш. А уж NTLM хэш в SAM гарантировано не является пустышкой.
Хотя, разумеется, вскрытый простой пароль из LM хэша дал бы гораздо больше возможностей.

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