Barmaley
CTEPX
Этот фокус уже не работает, что легко проверить.
Даже на старых системах это все тутже закрывалось умными админами редактированием реестра. Кстати, запуск с правами админа этого скринсэйвера невозможен принципиально, откуда система знает права админа?, так что максимум что может быть - либо SYSTEM либо NOBODY
.
Вообще говоря такие темы действительно безжалостно убиваются, но потом подумалось, чтоб вопросов было меньше, может стоит один раз написать что делать? Только в контексте именно обеспечения защиты, а не взлома, кто умный сам поймет что надо делать или что не надо делать соответственно.
Начальные данные - права пользователя или ниже, система на базе Windows NT. Задача - получить доступ с правами группы администраторов (именно группы, права администратора могут существенно отличаться). Варианты, не относящиеся непосредственно к системе безопасности (как то, выспросить админский пароль по телефону, перехватить почтовый трафик с паролем случайно совпавшм с админским, пытки админа загонянием раскаленных игл под ногти или еще как, в том числе случайно), не обсуждая их возможную применимость, я описывать не буду. Обычно задача получения повышенных прав равносильна задаче запуска процесса под системной учетной записью (мы же решили, что паролей мы не знаем).
Итак, взлом 1-го типа - это использование ошибок в системе, которые НЕ могут быть устранены администратором без изменения кода системы. Сюда относится тот самый DbgXploit, о котором написано выше, работает замечательно, но все админы, кому не пофигу, уже давно поставили заплатки и сервиспаки - это единственный способ защиты от ошибок в системе, администратор обязан своевременно все это устанавливать. Никто ведь уже кроме специалистов и не вспомнит GetAdmin.
Все оставшиеся ошибки - ошибки на совести администратора, и если удается их использовать - администратор однозначно зря получает свою зарплату.
Систематические администраторские ошибки заключаются в том, что не ограничивается доступ пользователей в те места, откуда можно управлять системой, в плане запуска программ под системной учетной записью это следующе места:
1) В реестре в [hklm\ system\ ccs\ control\ session manager] параметр BootExecute. Запуск программ отсюда имеет свою специфику, обычную программу оттуда не запустить, но в принципе, использовать этот ключ труда не представляет. Обработка его происходит на самом раннем этапе загрузки системы и программа, запускаемая оттуда, может в том числе заменить практически любой файл.
2) В реестре в [hklm\ software\ microsoft\ windows nt\ current version\ winlogon] параметр System. В нем перечисляются программы, запускаемые при входе пользователя в систему, причем запускаются под системной учетной записью. Запустить отсюда можно любую программу, ограничений на версию ее подсистемы или требуемые ей ресурсы не накладывается.
3) В реестре в [hklm\ Software\ Policies\ Microsoft\ Windows\ System\ Scripts] перечисляются скрипты для запуска при различных системных событиях, в частности, при запуске и завершении работы. Доступ на изменение как к этому ключу, так и к скриптам, должен у пользователя отсутствовать.
4) У пользователя не должно быть права редактировать профиль другого пользователя (в том числе реестр для другого пользователя) и общесистемный список автозапуска, в этом случае возможен запуск программ от имени другого пользователя.
5) У пользователя не должно быть право изменять обработчики расширений, запускаемых файлов, копирования, контекстного меню и тому подобного, одним словом, всего того, что так удобно, но небезопасно. В общем случае, у пользователя не должно быть права редактировать раздел реестра [HKCR]. Кроме того, многие приложения сохраняют информацию о своих модулях расширения в HKLM и HKCU - там тоже должен быть ограничен доступ, например, [HKLM\ SOFTWARE\ Microsoft\ Internet Explorer\ Extensions].
6) У пользователя не должно быть права изменять параметры запуска компонентов системы, в частности, служб, и не должно быть права подменять эти компоненты, в частности, службы (в том числе, не должно быть возможности доступа к жесткому диску при загрузке в другой системе, например, с другого раздела, и должны быть выборочно ограниченны права к системной папке и к Program Files и к прочим типа wwwroot, тут уж у кого что установлено). Вообще говоря, пользователь не должен иметь права на запись в весь раздел [hklm\ system].
7) Пользователь не должен иметь возможность управлять доверенными компонентами системы, в частности, если служба позволяет запуск процессов под системной учетной записью, доступ к ней должен быть закрыт. В качестве примера приведу Центр Управления от антивируса Касперского, в нем есть возможность запуска задачи пользователя от имени системной учетной записи.
8) У учетной записи пользователя не должно быть слишком больших привилегий. Например, одна лишь привилегия отладки полволяет запускать произвольный процесс от имени системной учетной записи, привилегия создания маркера и замены маркера уровня процесса - запуск процесса под любой учетной записью и с любыми привилегиями вообще, в том числе может быть указана вообще несуществующая учетная запись, про привилегию загрузки и выгрузки драйверов я вообще молчу, привилегии BACKUP/RESTORE позволяют заменять любые файлы, в том числе открытые, и еще много чего - функциональность, не нужная пользователю.В принципе, можно упомянуть еще кучу потенциально опасных привилегий, как то TCB или Take Ownership, но в общем-то ясно, что это больше умозрительная дыра, если админ дает юзеру привилегию отладки - у него либо должна быть уверенность, что юзер не знает, насколько это мощная привилегия, либо он готов, что в один прекрасный момент у юзера появятся админские права, либо он просто сумасшедший.
Может еще чего добавится, это что с ходу написалось, дополнения приветствуются, но именно в контексте защиты системы, а не взлома.
