7

Итак, я знаю, что во многих вариантах Unix вы можете настроить пользователя root / admin, обычного пользователя и т.д. И по умолчанию иногда в некоторых дистрибутивах Linux у суперпользователя root есть пароль по умолчанию. Например (только для примера) в дистрибутиве Oracle Linux пароль по умолчанию может быть просто «оракул».

Теперь, что касается Windows, я пытаюсь войти в системную учетную запись, так как доступ запрещен даже из-за того, что «Администратор» на компьютере, например, regedit, все еще может отказать мне в доступе.

Я заметил, что в планировщике задач и некоторых других областях, кажется, есть какой-то специальный или зашифрованный пароль для пользователей «LocalService» и «NetworkService», которые Microsoft запрограммировала на такие вещи, как запуск планировщика задач, запуск фоновых процессов и т.д. Так что, если есть способ узнать пароли по умолчанию, используемые для этих учетных записей, это может помочь. Если не удастся просто дешифровать их, я переустановлю их, если что-нибудь.

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

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

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

Спасибо за вашу помощь!

С уважением

1 ответ1

8

Учетные записи SYSTEM и NETWORK SERVICE не являются реальными учетными записями и не существуют в SAM - другими словами, они не могут иметь установленный пароль, и вы не можете войти в них. Они существуют только как «общеизвестные SID» (идентификаторы безопасности) - Windows просто предоставляет особый режим для таких SID, как S-1-5-18 или S-1-5-20 , подобно тому, как uid 0 является особенным в Unix, и привилегированные программы могут использовать эту учетную запись, создавая сами токены (аналогично вызову setuid()+capset() в Unix).

Простой способ запуска программ с привилегиями SYSTEM - через PsExec от Sysinternals:

psexec -dsi cmd

Однако, в отличие от корня Unix, даже SYSTEM не разрешено обходить объектные ACL - поэтому все записи реестра, системные файлы и другие вещи явно показывают SYSTEM в своих ACL. Вместо этого, если администратору по какой-то причине необходимо переопределить ACL объекта, он может стать владельцем этого объекта с помощью SeTakeOwnershipPrivilege 1 (предоставляется по умолчанию всем администраторам). Это работает, потому что владельцу объекта всегда разрешено изменять свои ACL, даже если они явно отрицают это; это только 2 исключения для Windows делает.

Иногда доступ запрещен по другим причинам - многие антивирусные программы поставляются с драйверами ядра "самообороны", которые исправляют различные функции в самом ядре Windows и заставляют их отклонять изменения определенных ключей или файлов, основываясь исключительно на их имени; блок находится перед выполнением первоначальных проверок ACL, и никакие разрешения или привилегии не могут его переопределить. Единственный способ обойти такую защиту - отменить модификации ядра; для этого можно использовать любой отладчик ядра. Такие инструменты, как Kernel Detective, могут перечислять все записи в SSDT, какой драйвер ядра изменил какую функцию, и даже иметь команды для сброса значений по умолчанию.


1 Если вам интересно, вы можете использовать Process Explorer для просмотра всех идентификаторов безопасности и битов привилегий, назначенных конкретному процессу. Вы увидите, что даже системные процессы не имеют каких-либо общих привилегий "переопределения безопасности" ; вместо этого существуют только определенные привилегии, такие как SeImpersonate, SeTakeOwnership или SeCreateToken .

2 Для файлов кто-то, владеющий SeBackupPrivilege, может прочитать файл в "режиме резервного копирования" - в архиве, содержащем данные, метаданные, списки ACL, права собственности ... - затем при желании изменить его и снова восстановить в файловой системе. То есть если предположить, что кто-то изменил структуру этих резервных архивов. Это недоступно для других видов объектов.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .