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

Редиректор (redirector) обеспечивает средства межсетевого взаимодействия и предоставляет доступ к файлам, именованным каналам (Named Pipe), почтовым ящикам (Maillots) и принтерам, расположенным на удаленной машине.

В Windows NT редиректор реализован как драйвер файловой системы, доступный в системе через устройство “\Device\Redirector”, которое создает надстройку над протоколами транспортного уровня, позволяющую работать с соединениями точно так, как с файлами. В частности в обязанности редиректора входит корректная обработка и восстановление разрывов соединения.

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

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

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

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

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

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

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

Существует программная реализация такой атаки, созданная Вадимом Проскуриным, совместно с Петром Девяниным и Сергеем Заливакиным. Программа AdminTrap (http://hackzone.ru/articles/AdmTrap.zip) создает троянский экземпляр одного из системных каналов и ждет подключения клиента. Если получение прав администратора происходит успешно, в качестве демонстрации работоспособности программы, создается новый пользователь в группе «Администраторы», но для предотвращения несанкционированного доступа вновь созданная учетная запись тут же блокируется. Очевидно, разработчики не ставили перед собой целью вторжения в чужие системы, а стремились показать наличие такой уязвимости.

Тут можно пофилософствовать, что будет, если эта информация попадет в руки злоумышленника, ведь для перехвата каналов достаточно иметь начальные навыки программирования и хотя бы поверхностно разбираться в win32 API. Или вдруг найдется хакер, который незначительным исправлением программы AdminTrap, добьется разблокировки учетной записи?

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

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

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

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

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

Вот так описывает Вадим Проскурин реакцию системы на создание бесчисленного количества экземпляров системных каналов: