Техника сетевых атак
Шрифт:
Поэтому, в Windows NT существует возможность предоставления каждому пользователю своей собственной корзины. При нормальном развитии событий, никакой пользователь, не обладающий правами администратора, не может получить доступ к чужой корзине. Но друг от друга корзины отличаются всего лишь идентификатором пользователя SID, который злоумышленнику легко выяснить (существуют API функции, выдающие идентификатор пользователя по его имени). Если злоумышленник изменит идентификатор свой корзины на идентификатор корзины жертвы, то файлы, удаляемые жертвой, попадут в руки злоумышленника.
Впрочем, существование двух корзин с одинаковыми идентификаторами приводит к непредсказуемому поведению системы, поэтому стабильная работа обеспечивается лишь в том случае, когда злоумышленник подделывает свою корзину до создания корзины жертвы, что маловероятно, т.к. обычно корзина создается сразу же после регистрации нового пользователя системы. Но до регистрации пользователя не известен его SID.
Таким образом, подобная уязвимость не представляет больной опасности, но все же достаточно любопытна сама по себе.
Но если в коде ядра операционной системы присутствуют ошибки, позволяющие пользователю вмешиваться в работу системных процессов, то злоумышленник сможет получить любые привилегии, в том числе и администратора! Изучая работу модуля ntoskrnl.exe, Константин Соболев (sob@cmp.phys.msu.su) обратил внимание на то, что функция “NtAddAtom” не контролирует значение аргумента, указывающего адрес для записи результатов успешности своей работы. Поскольку функция “NtAddAtom” выполняется ядром и имеет привилегии System, она может писать, что ей вздумается и куда вздумается. Но функция win32 API “AddAtom”, содержит переходной код, который сохраняет результат работы “NtAddAtom” в локальной переменной, откуда и возвращает значение пользователю. Однако через программное прерывание 0x2E можно получить доступ непосредственно к функциям ядра, без высокоуровневых оберток.
Ниже приведен фрагмент программы “GetAdmin”, написанной Константином Соболевым, которая позволяет пользователю получать права администратора.
· for(i=0;i«0x100;i++)
· {
· sprintf(string,"NT now cracking… pass %d",i);
· if(handle amp; 0xf00){
· stack[1] = (DWORD)pNtGlobalFlag+1;
·}
· __asm
· {
· mov eax, callnumber;
· mov edx, stack;
· lea edx,dword ptr [stack]
· int 0x2e;
·}
· if(stack[1] - pNtGlobalFlag+1)
· break;
Реакция Microsoft в описании Соболева выглядит так: «30 июля 1997 я послал письмо в Microsoft, что так и так, есть такой баг. Через пару дней получил ответ от господина N, что я ошибся, и вообще моя программа не работает. Послав программу на www.ntsecurity.net и на news я убедился, что она все-таки работает. После публикации мне пришло письмо от господина NN из Microsoft (должностью повыше, чем N) с просьбой сообщить имя господина N».
Другая ошибка (правда, на этот раз не ядра, а прикладного сервиса) связана с неправильной обработкой относительных путей файлов и каталогов, доступных через протокол SMB. Если у злоумышленника есть доступ хотя бы к одному из каталогов на удаленной машине, он сможет добраться и до остальных, используя конструкцию “…\\”. Правда, ему потребуется создать свою реализацию клиента, ибо клиенты, поставляемые Microsoft выполняют дополнительные проверки и для атаки непригодны.
Вообще же, если у пользователя есть право отладки приложений, ему должны быть доступны функции “WriteProcessMemory” и “CreateRemoteThread”, позволяющие как угодно распоряжаться системой по своему усмотрению. Поскольку, ни один здравомыслящий администратор потенциальному злоумышленнику такого права не даст, тому приходится присваивать его самостоятельно. К сожалению, описание алгоритма такой атаки выходит за рамки данной книги, но существует утилита Sechole, написанная Prasad Dabak, Sandeep Phadke и Milind Borate, которая замещает код функции “OpenProcess” (проверяющий наличие прав отладки приложений перед открытием процесса) и затем, пользуясь отладочными функциями, помещает текущего пользователя в группу администраторов.
Служба редиректора так же имеет ошибки реализации, позволяющие любому пользователю получить права администратора или нарушить нормальную работу сервера, поэтому имеет смысл подробно остановится на этом моменте.
Редиректор (redirector) обеспечивает средства межсетевого взаимодействия и предоставляет доступ к файлам, именованным каналам (Named Pipe), почтовым ящикам (Maillots) и принтерам, расположенным на удаленной машине.
В Windows NT редиректор реализован как драйвер файловой системы, доступный в системе через устройство “\Device\Redirector”, которое создает надстройку над протоколами транспортного уровня, позволяющую работать с соединениями точно так, как с файлами. В частности в обязанности редиректора входит корректная обработка и восстановление разрывов соединения.
Именованные каналы представляют собой механизм межсетевой передачи данных по виртуальному каналу, гарантирующему доставку сообщений. (Почтовые ящики не гарантируют доставку сообщений и процесс-отправитель не получает уведомление получил ли адресат сообщение или нет). Каналы реализованы в виде псевдофайловой системы NPFS (Named Pipe File System), которая хранит все сообщения в памяти и выдает их по запросу. Имена сообщений представляются в виде “\pipe\pipaname” и они работают с теми же функциями, что и обыкновенные файлы (например, CreateFile, ReadFile, WriteFile).
Создать именованный канал (или новый экземпляр существующего канала, если такой канал уже есть) позволяет функция CreateNamedPipe. Каждый экземпляр канала одновременно может работать лишь с одним клиентом. Поэтому, при создании канала, сервер сразу же открывает несколько экземпляров канала. В документации Microsoft утверждается, что при запросе на подключение система соединяет клиента с любым незанятным экземпляром канала, но эксперименты показывают, - клиент всегда подключается к наиболее ранее созданному (или освобожденному) каналу.
Создать экземпляр уже существующего канала может любой процесс, независимо от его привилегий и прав доступа. Система примет новый экземпляр канала на равных правах со старым. И когда все созданные ранее экземпляры окажутся занятыми, очередной клиент, желающий установить соединение, будет отослан к подложному каналу. Но функции API не позволяют клиенту узнать, какой процесс обрабатывает канал, с которым клиент установил соединение!
Это дает возможность внедрять ложные объекты в вычислительную систему и перехватывать входящий трафик. Более того, существует возможность унаследовать права клиента! Процессу, породившему экземпляр канала, достаточно вызвать функцию ImpersonateNamedPipeClient, выполняющую олицетворение (Impersonate) клиента. Вообще-то, эта функция задумывалась как раз для обратного - понижения привилегий потока, выполняющего олицетворение.