Який обліковий запис Windows використовується, коли ніхто не входить у систему?


25

Якщо у Windows ніхто не входить (на екрані входу відображається), яким користувачем працюють поточні процеси? (Драйвери відео / звуку, сеанс входу в систему, будь-яке серверне програмне забезпечення, засоби управління доступністю тощо. Вони не можуть бути жодним користувачем або попереднім користувачем, тому що ніхто не входив у систему. Що з процесами, які розпочав користувач, але продовжує запустити після виходу з системи? (наприклад, HTTP, FTP-сервери та ін. мережеві речі). Чи переходять вони на обліковий запис SYSTEM? Якщо процес, що розпочався користувачем, переходить на SYSTEM, що свідчить про дуже серйозну вразливість. Чи працює процес як цей користувач продовжувати працювати як цей користувач після виходу з системи?

Ось чому хак SETHC дозволяє використовувати CMD як SYSTEM?


"Перемикання користувачів" насправді не є чорно-білою операцією в Windows. Сервіс може представити себе декількома користувачами одночасно, а також використовувати оригінальний обліковий запис. Це корисно для служб, які повинні діяти від імені конкретних користувачів, скажімо, аутентифіковані відвідувачі веб-сайту.
MSalters

3
Windows - це багатокористувацька операційна система, що означає, що різні процеси можуть належати різним користувачам одночасно . Це не так, як тільки ввівши весь комп'ютер "перемикається" на ваш рахунок.
el.pescado

Відповіді:


40

Якщо у Windows ніхто не входить (на екрані входу відображається), яким користувачем працюють поточні процеси? (Драйвери відео / звуку, сеанс входу, будь-яке серверне програмне забезпечення, засоби керування доступністю тощо.

Майже всі драйвери працюють у режимі ядра ; їм не потрібен обліковий запис, якщо тільки вони не запустять процеси в просторі користувачів. Кілька драйверів простору користувачів працюють під системою SYSTEM.

Сеанс входу, я зараз не можу перевірити, але впевнений, що він також використовує SYSTEM. Ви можете побачити logonui.exe в Process Hacker або SysInternals ProcExp . Насправді ви все можете бачити саме так.

"Серверне програмне забезпечення", див. Служби Windows нижче.

Що з процесами, які були розпочаті користувачем, але продовжують працювати після виходу з системи? (Наприклад, HTTP, FTP-сервери та інші матеріали для мереж). Чи переходять вони на рахунок СИСТЕМИ?

Тут є три види:

  1. Прості старі "фонові" процеси. Вони працюють під тим самим обліковим записом, що і хто запустив їх, і не запускаються після виходу з системи. Процес виходу з системи вбиває їх усіх.

    "HTTP, FTP-сервери та інші мережеві матеріали" не працюють як звичайні фонові процеси. Вони працюють як служби.

  2. Процеси "служби" Windows. Вони запускаються не безпосередньо, а через Service Manager. За замовчуванням служби запускаються як LocalSystem (що каже isanae, що дорівнює SYSTEM), хоча вони можуть мати спеціальні облікові записи.

    (Звичайно, практично ніхто не заважає. Вони просто встановлюють XAMPP або WampServer або якусь іншу лайну, і нехай вона працює як SYSTEM, назавжди не виправлена.)

    В останніх системах Windows я думаю, що сервіси також можуть мати власні SID, але я ще цього не вивчив.

  3. Планові завдання. Вони запускаються службою "Планувальник завдань" "у фоновому режимі" і завжди працюють під обліковим записом, налаштованим у завданні (як правило, хто створив завдання).

Якщо процес, запущений користувачем, переходить на SYSTEM, це вказує на дуже серйозну вразливість

Це не вразливість, оскільки ви вже повинні мати права адміністратора, щоб встановити службу. Наявність привілеїв адміністратора дозволяє вам робити практично все.

(див. також різні інші невразливі місця такого ж роду)



2
Можливо, варто відзначити, що значна частина IIS працює поза нижчими привілейованими обліковими записами, створеними спеціально для IIS-процесів. (Це охоплює багато серверів Windows HTTP, FTP тощо.) Детальну інформацію див. Тут . Тому це часто залежить від стандартних налаштувань будь-якої програми, яку ви використовуєте.
jpmc26

1
SYSTEM і Local Administrator - це по суті одне і те ж. Після того, як у вас є один, ви можете отримати інший, і ОС лише встановлює блокпости, призначені насамперед для запобігання помилок. (Примітка . Стара Нова річ не є офіційною документацією Microsoft.)
CVn

3
У наші дні багато служб працюють як NetworkService або LocalService, а не LocalSystem.
Бен Войгт

2
Починаючи з Windows 7 та 2008 R2, облікові записи керованих служб та віртуальні облікові записи дозволяють запускати сервіси під власною ідентичністю, тому у вас немає купу служб, що обмінюються LocalService / NetworkService / LocalSystem, обмежуючи доступ, якщо одна служба має вразливість.
afrazier

2

Процеси входу та попереднього входу в систему виконуються як СИСТЕМА (також називається LocalSystem). Насправді, одним із способів отримати оболонку (наприклад, підказку CMD), запущену як SYSTEM на деяких версіях Windows, є заміна програми доступності, наприклад, зчитувача екрана, лупи або екранної клавіатури, на копію (або посилання на) CMD.EXE, а потім скористайтеся ярликом, щоб увімкнути цю функцію доступності перед входом у систему. Ви отримаєте командний рядок, навіть не маючи користувачів, які ввійшли в систему, і CMDпрацюватимуть як SYSTEM.

(Зауважте: очевидно, що це небезпечно, оскільки дозволяє людям обходити процес входу в Windows. Ніколи не слід налаштовувати комп’ютер таким чином, а потім залишати його таким.)


1
Працює в Windows 7, замінив sethc.exe на cmd.exe на C: \ Windows \ System32 \

1

Вони ні на що не «переключаються»; такі процеси ніколи не запускаються в поточному контексті користувача.
Вони належать SYSTEMкористувачеві.

Будь-які процеси та послуги, що належать окремому користувачу, припиняються після виходу.
Ось що означає вихід із системи .


Я не впевнений ... По-перше, я знайшов посаду MS Technet, де (не так, як це означає багато) відповідь, прийнята персоналом, заявила, що послуги не припиняються при виході. Я не впевнений, що це точне визначення виходу, як правило: я побачив кілька демонів у Linux, коли я вийшов з одного користувача, а потім psяк іншого
underscore_d

1
Це не правильно. Служби можна запустити як інший користувач, і вони будуть запускатися та продовжувати працювати без того, щоб цей користувач "увійшов". Вони розпочнуть власний сеанс з використанням даних облікових даних користувачів, тому власне користувач буде входити в систему під час роботи служби, але програми настільних / автозапуску тощо не запускаються, і це те, що звичайні користувачі розуміють як "увійшли в систему". Поки сервіс працюватиме з даними облікових даних користувачів та матиме доступ до файлів цих користувачів.
Йозеф

@Josef: Схоже, ваш аргумент зводиться до того, що "деякі люди неправильно використовують термін" увійшов у систему "". Фактичне м'ясо Вашого коментаря погоджується з моєю відповіддю: цей користувач вважається зареєстрованим до тих пір, поки вони мають послуги / процеси, що працюють проти їх облікового запису.
Гонки легкості з Монікою

@LightnessRacesinOrbit немає, є фактична різниця. Якщо ви створили службу зі своїм обліковим записом, і вона запускається під час завантаження, то для показу робочого столу не буде запущено жодного процесу (щоб не було запущено dwm.exe або explorer.exe), всі ваші програми автозапуску не будуть Запуск тощо. Отже, якщо у вас інтерактивний сеанс входу, активніше набагато більше речей, ніж якщо працює лише сеанс обслуговування. Що саме "увійшов", відкрито для дискусій. Навіть якщо служба працює з вашими обліковими даними, вам все одно доведеться увійти, щоб користуватися Windows самостійно!
Йозеф

1
Що ж, "такі процеси ніколи не запускаються в поточному контексті користувача" все одно неправильно. Служби запускаються у встановленому для них контексті користувача. Для вбудованих служб Windows, це один із системних облікових записів. Для інших послуг це може бути будь-який рахунок. Особливо серверне програмне забезпечення повинно створити новий обліковий запис користувача та мати відповідні облікові дані.
Йозеф
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.