У logon-сесіях Windows зберігає інформацію про будь-яких успішних входах в систему. Інформація включає в себе ім'я користувача, ім'я робочої групи або домену, а також LM / NT-хеш-кодування паролів.
Автор: Bernardo Damele A. G
Logon-сесії
У logon-сесіях Windows зберігає інформацію про будь-яких успішних входах в систему. Інформація включає в себе ім'я користувача, ім'я робочої групи або домену, а також LM / NT-хеш-кодування паролів.
Незалежно від того, як саме легітимний користувач заходить в систему: інтерактивно або віддалено через RDP - в будь-якому випадку, локальна підсистема безпеки (Local Security System - LSA) зберігає облікові дані користувачів в пам'яті.
Нижче представлена модель входу і аутентифікації в Windows NT:
Модель входу і аутентифікації в Windows NT
Аналогічні дані зберігаються і для процесів, "запускаються від імені ..." ( Run As ) І служб, що виконуються в контексті певного користувача. Паролі служб зберігаються в незашифрованому вигляді, і можуть бути отримані з секретів LSA .
Проте, при аутентифікації по мережі (наприклад, по протоколах SMB або HTTP) logon-сесії зберігатися не будуть, оскільки NT / LM-хеш-кодування в дійсності не передаються на сервер ¬- для аутентифікації використовується механізм типу "запит-відповідь".
Система зберігає в пам'яті конфіденційну інформацію користувачів для того, щоб використовувати технологію єдиного доступу (Single Sign-On (SSO)). Технологія SSO широко застосовується в мережах Windows, і особливо всередині доменів. SSO дозволяє користувачеві одного разу аутентифицироваться в системі і отримати доступ до ресурсів, що розділяються, (принтери, HTTP-проксі і.т.п.) без необхідності повторного введення своїх облікових даних: Windows скористається зберігається в пам'яті інформацією (ім'я користувача, домен / робочу групу, хеші паролів) і прозоро для користувача аутентифікує його.
Механізм SSO функціонує завдяки тому, що сьогодні практично всі сервіси Windows (винятком є підключення по RDP) поряд з аутентифікацією по паролю підтримують аутентифікацію по NT / LM-Хешам.
Отримання logon-сесій
Logon-сесії можна отримати, за умови, що у вас є доступ до командного рядка з адміністративними правами. Існує два методи отримання logon-сесій: впровадження коду в процес lsass.exe і читання пам'яті LSASS.
Наступні утиліти допомагають злити logon-сесії: msvctl від TrueCrypt ідеально підходить для 32-бітних Windows XP / 2003. остання версія gsecdump зіллє logon-сесії в незалежності від версії і архітектури Windows. З недавніх розробок TrueSec варто також відзначити lslsass : Утиліта була спроектована спеціально для систем Windows Vista і вище. Lslsass бездоганно працює як на 32-x, так і на 64-x розрядних системах.
Найвідоміші утиліти для управління logon-сесіями Windows - це Windows Credentials Editor (WCE) і її попередниця Pass-the-Hash Toolkit (PTK). Обидві утиліти являють собою результат плідної роботи засновника компанії Amplia Security Хернан Очоа (Hernan Ochoa). За своїми розробками він зробив кілька презентацій, серед яких:
З двох утиліт я по ряду причин волію WCE: по-перше, WCE - це самостійний EXE-файл; по-друге, WCE безпечніше, оскільки не призводить до падіння процесу LSASS при читанні пам'яті; і по-третє, утиліта працює на всіх версіях і архітектурі Windows.
Спеціально для цілей статті я встановив Windows Server 2003 Service Pack 2 з усіма оновленнями (NetBIOS-ім'я w2k3r2), і справив такі дії:
- Локальний користувач Administrator інтерактивно зайшов на консоль. Довжина пароля користувача Administrator - 15 символів.
- Два локальних користувача inquis і foobar підключилися до системи по RDP. Перший користувач підключився через mstsc, а другий через rdesktop.
- Запущено кілька сервісів СУБД IBM DB2 в контексті локального адміністратора db2admin.
Утиліта lslsass була навмисно виключена з експерименту, так як вона працює тільки на системах Windows Vista і вище.
Всі тестовані утиліти вдало злили logon-сесії. Нижче показаний результат роботи Windows Credential Editor:
C: \> wce.exe -l
WCE v1.2 (Windows Credentials Editor) - (c) 2010,2011 Amplia Security - by
Hernan Ochoa ([email protected])
Use -h for help.
Administrator: W2K3R2: 00000000000000000000000000000000: 237599E85CF684A67
85A12ACD2E24E5C
inquis: W2K3R2: 0AC9A586623764E16591BB5472A3AD4A: 89F411F435A93044E2E8AA4CEDF
E0FBA
foobar: W2K3R2: 87DCEB9223BE0E08FD8E74C8CEB3053A: 33D807D89B36ACDF2FAB42A361D
E0B91
db2admin: W2K3R2: 3AE6CCCE2A2A253F93E28745B8BF4BA6: 35CCBA9168B1D5CA6093B4B7D
56C619B W2K3R2 $: WORKGROUP: AAD3B435B51404EEAAD3B435B51404EE: 31D6CFE0D16AE931B73C59D
7E0C089C0
Ми отримали ім'я користувача, ім'я домену / робочої групи і LM / NT-хеш-кодування. Результати тестованих утиліт і утиліт для отримання хешу з SAM дуже схожі, за винятком того, що тестовані утиліти можуть відобразити облікові дані не тільки локальних, але і доменних користувачів теж.
Наступний скріншот також підтверджує вдалість атаки:
Отримання logon-сесій за допомогою Windows Credential Editor (WCE) на Windows Server 2003 R2
(Administrator має доступ до консолі, два користувача підключені віддалено по RDP і один процес виконується в контексті локального користувача)
Під час проведення експерименту я зрозумів, що незалежно від того, як саме завершуються сесії, logon-сесії все одно залишаються в пам'яті. Наприклад, неважливо як ви закриєте RDP-з'єднання: натиснете X в лівому верхньому кутку RDP-клієнта або вийдете з системи через меню "ПУСК" - logon-сесія все одно залишиться в пам'яті. Подібні речі відбуваються і в Windows Server 2008 R2 Enterprise Service Pack 1. У системах Windows Vista і вище logon-сесії стираються з пам'яті через пару хвилин після виходу користувача з системи.
Вищеописане поведінка продемонстровано на наступному скріншоті:
Отримання logon-сесії після відключення від RDP користувача foobar: його logon-сесія залишилася в пам'яті
Отримання logon-сесії після примусового відключення від RDP користувача foobar: його logon-сесія залишилася в пам'яті
Logon-сесія db2admin також залишилася в пам'яті, не дивлячись на те, що відповідний сервіс був зупинений.
Які загрози тягне за собою отримання logon-сесії
Ситуація зараз така ж, як і при отриманні секретів LSA і інформації з кешованих входів в домен: ви отримали права Local System на системі, що входить в один або декілька доменів, і ви хочете взяти під контроль весь домен (домени).Ніякої інформації про облікових даних доменних користувачів із секретів LSA і з кешу вам дізнатися не вдалося.Тоді спробуйте злити logon-сесії. Якщо вам вдасться отримати logon-сесію доменного адміністратора, то ви перемогли: залишилося тільки використовувати отриману logon-сесію, щоб видати себе за адміністратора і отримати доступ до командного рядка. Така атака також відома, як "pass-the-hash" ( "передача хешу") або крадіжка logon-сесії.
У командному рядку наберіть наступне:
C: \> wce.exe -s ::: -c cmd.exe
У новому вікні командного рядка підключіться по SMB (наприклад, за допомогою утиліти PsExec компанії Sysinternals) до кореневого контролера домену. Система, швидше за все, успішно аутентифікує вас як адміністратора домену, тому що, по суті, ви надали облікові дані саме цього користувача.
Якщо ж logon-сесії адміністратора домену на захопленій вами системі немає, то перевірте (за допомогою утиліти keimpx ), На які ще системи в домені користувач може увійти. Є ймовірність, що нові захоплені системи містять необхідну вам інформацію про облікових даних адміністратора домену, і тому, повторюючи ті ж самі дії, вам, можливо, вдасться захопити контролер домену.
Крім WCE є і багато інших програм, здатні провести атаку передачі хешу: наприклад, msvctl і RunhAsh від TrueSec. Всі нові утиліти я додав в таблицю . Буду радий вашим відгуків і пропозицій!
