1. Зміст статті Не знаю, чим керувалися люди з Microsoft, коли проектували і створювали систему групових...
2. Трюк 1. Обходимо завантаження політик
3. Трюк 2. Як відбувається перевірка політик?
4. Трюк 3. Обходимо SRP
5. Трюк 4. Binary planting
6. Трюк 5. Використовуємо виключення
7. Трюк 6. Використовуємо змінні середовища
8. Трюк 7. Використовуємо іншого користувача
9. Трюк 8. Згадуємо про HTA
10. Групові політики в тонких клієнтах
11. наш підсумок

Зміст статті

Не знаю, чим керувалися люди з Microsoft, коли проектували і створювали систему групових політик в Windows, але вийшло у них не дуже. Система вийшла гнучкою та функціональної, але з чималою кількістю лазівок, що дозволяють обійти обмеження і дістатися до тих місць ОС, доступ до яких заборонений.

По правді кажучи, групові політики були досліджені уздовж і поперек ще п'ять років тому. Однак використовувані рішення мало чим змінилися. Багато баги і раніше працюють. Крім того, з'являються нові прийоми для обходу групових політик. Тому ми вирішили зібрати для тебе деякий набір рецептів, щоб ти, по-перше, міг взяти на озброєння, а по-друге, перестав вірити в те, що групові політики - це панацея. При всій зручності їх використання вони не можуть забезпечити належний рівень захисту. Але про все по порядку.

Що таке Групові політики (Group Policy)?

Якщо вірити нудним визначень, то групові політики (або Group Policy) - це ефективний і централізований механізм управління численними параметрами операційних систем і додатків. Групові політики дозволяють адмінам визначати правила, відповідно до яких настроюються параметри робочого середовища як для користувачів, так і для комп'ютерів. Простіше кажучи, це досить потужний інструмент для обмеження в діях звичайних користувачів. Існує маса різних політик і прав, за допомогою яких можна заборонити виклик диспетчера задач або редактора реєстру, заборонити доступ до меню «Пуск», а також досить гнучко обмежити запуск програмного забезпечення (це реалізується за допомогою так званих Software Restriction Policies). Чи є цей механізм ефективним? Лише частково. Доступ до шорткати, запуск лівого ПО і системних додатків, зміна налаштувань - все це досить легко забороняється за допомогою групових політик, і з цієї точки зору можна сказати спасибі розробникам ОС. Але, на жаль, як це зазвичай буває, ці політики часто можна обійти. Тут варто зробити застереження. Всі політики можна розбити на дві категорії - для комп'ютерів і для користувачів. Групові політики доступні як в домені, так і на локальному компі. Якщо мова йде про локальній машині, то їх можна подивитися через спеціальне оснащення gpedit.msc (secpol.msc). У даній статті основний акцент зроблений саме на доменні групові політики. Отже, приступимо.

Трюк 1. Обходимо завантаження політик

Давай розберемося, як взагалі кожна машина в локальній мережі отримує групові політики з домену? Процес створення групових політик можна розбити на наступні умовні етапи:

1. Адмін створює об'єкт групової політики.
2. Прив'язує його до якихось елементів домену.
3. При вході в домен комп відправляє запит на отримання політик і отримує їх у відповідь від домену.
4. При вході користувача виконується аналогічний запит, але вже по призначених для користувача політикам.

Отже, що ми тут бачимо: політики завантажуються на стадії входу в систему. Тут є невелика фіча. За замовчуванням оновити регламент виконується кожні 5 хвилин. Але якщо політики не були отримані під час входу в систему, то оновлюватися вони не будуть! Вимальовується елементарний спосіб, як цю особливість можна використовувати:

1. Виймаємо патч-корд з компа.
2. Включаємо комп і логіном під своєю учеткой.
3. Підключаємо патч-корд назад.

Навіть при відсутності доступу в мережу ми зможемо увійти в домен, так як винда раніше закеширувалася наш логін і пароль (це сталося під час попереднього входу в систему). Але вже без застосування групових політик. При цьому ми спокійно зможемо використовувати ресурси мережі, так як патч-корд до цього моменту буде на місці, а з усякими авторизації на віддалених ресурсах впорається сама вінда. Варто додати, що в безпечному режимі вінди групові політики взагалі не діють. Коментарі, я думаю, зайві.

Трюк 2. Як відбувається перевірка політик?

Важливо розуміти, на якому етапі відбувається зіставлення дії, яке хоче виконати користувач, з тими обмеженнями групових політик, які на нього накладаються. Спершу давай розберемося, де розташовані політики. Спочатку, звичайно, на контролері домену, звідки вже передаються на машини в локальній мережі. Після отримання групових політик на клієнтській машині вони зберігаються в реєстрі вінди в наступних місцях (наведені основні гілки):

Політики для компа:

• HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsCurrentVersionPolicies
• HKEY_LOCAL_MACHINESoftwarePolicies

Політики для користувачів:

• HKEY_CURENT_USERSoftwareMicrosoft WindowsCurrentVersionPolicies
• HKEY_CURENT_USERSoftwarePolicies

Коли запускається якийсь процес, то в ньому (тобто в userspace'е) проводиться перевірка даних гілок реєстру (через підвантаженими бібліотеку advapi.dll) на ті чи інші обмеження, які потім кешуються / зберігаються в пам'яті процесу. Вони перевіряються, коли користувач виконує якусь дію, наприклад використання програмного продукту. У чому підступ? У тому, що контроль проводиться з самого процесу. Тобто якщо процес «не захоче» перевіряти політики, то ніщо його не змусить їх дотримуватися. Ніякого загального моніторингу не проводиться! Звідси висновок: якщо ми якимось чином зможемо запустити довільний процес, то політики нам уже не страшні. Зробити як правило - не проблема. Навіть якщо немає можливості закачати програму на хост, можна виконати її віддалено (наприклад, через кулі).

Трюк 3. Обходимо SRP

На жаль, далі на нашому шляху виникає інший механізм обмежень - SRP (Software Restriction Policies). Це група політик, за допомогою яких адмін може обмежити список ПО, яке може запускати користувач, через чорний і білий списки. Blacklist і Whitelist визначаються за допомогою правил, які можна задавати декількома способами: по зонам і за сертифікатами (перші два варіанти практично не використовуються), а також по шляху до файлу і по його хешу. Про те, що в системі діють політики SRP, вказує відповідний пункт в реєстрі - HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoft WindowsSafer CodeIdentifiersTransparentEnabled зі значенням більшим 0, який, як уже було сказано вище, перевіряється при запуску процесу. Наше завдання, відповідно, відрубати цю перевірку всередині запускається процесу. Марк Руссинович ще в далекому 2005 році опублікував пост в блозі про обхід SRP і представив ТУЛЗ GPdisable. Вона виробляє DLL-ін'єкцію в заданий процес, довантажуючи спеціальну DLL'ку. Коли процес спробує отримати значення ключа реєстру HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSafer CodeIdentifiersTransparentEnabled, тобто буде перевіряти присутність політик SRP, дана бібліотека перехопить запит і поверне STATUS_OBJECT_NAME_NOT_FOUND. Таким чином, процес думає, що все ОК і SRP політики в системі не діють. Після покупки компанії Sysinternals Майкрософтом GPdisable перестав був офіційно доступним (але його як і раніше легко знайти в Мережі . Є ще більш просунуті рішення. утиліта GPCul8or від Eric'a Rachner'a виконує аналогічні функції, але доступна в исходниках. Що це нам дає? Ми можемо додати в GPCul8or будь-які інші значення реєстру вінди (DisableTaskMgr, ProxySettingsPerUser наприклад) і таким чином обійти всі можливі обмеження політик. Які саме значення, запитаєш ти. Тобі в допомогу RegMon від Марка Руссиновича, хоча, по суті - це все значення з гілки Policies. Інший оригінальний спосіб в своєму блозі опублікував Дідьє Стівенс . Використовуючи свою ТУЛЗ bpmtk (Basic Process Manipulation Tool Kit), він запропонував прямо в пам'яті процесу змінювати значення необхідного для групової політики гілки реєстру.

Трюк 4. Binary planting

Утиліта GPdisable складається з двох файлів:

Як я вже сказав, якщо ми можемо запустити додаток, то можемо легко обійти SRP і інші політики (через GPdisable, bpmtk, GPCul8or - неважливо). Однак в реальній системі може виявитися не так вже просто запустити ці програми. Але ми можемо довантажити DLL (в тому числі gpdisable.dll). Тут є важливий нюанс. Групові політики при запуску ПО можуть перевіряти і DLL'кі, але при цьому досить сильно падає продуктивність системи, тому за замовчуванням ця опція відключена. І ми це можемо використовувати! Дуже до речі доводиться недавнє дослідження від компанії Across Security , Яке розповідає про нові (досить збочених, але працюють) методах подгрузки коду в процеси. Прийом називається Binary planting (і як його класичний приклад - dll hijacking), при його вивченні у мене виникла думка: «а чому не використовувати його для обходу групових політик?». Якщо система дозволяє запуск додатків тільки з білого списку (нехай навіть тільки Word), то цього вже достатньо, щоб довантажити нашу корисну DLL для обходу SRP. Отже, спробуємо схрестити dll hijacking від хлопців з Across і GPdisable:

1. Перейменовуємо gpdisable.dll в ehTrace.dll.

2. Створюємо папку з ім'ям куку. {2E095DD0-AF56-47E4-A099-EAC038DECC24} (назва будь-, текст після точки зникне).

3. Кидаємо ehTrace.dll в тільки що створену папку.

4. Заходимо в папку і створюємо там будь-який документ у Word, Excel або, наприклад, PDF'ку.

5. Тепер відкриваємо щойно створений файл.

6. Відповідна програма повинна запуститися. І запустити разом з підвантаженими DLL'кой!

7. Все, політики нам не страшні.

Трюк 5. Використовуємо виключення

Часто можна обійтися і без подібних хитрощів, якщо знати тонкощі політик, в результаті яких їх дії поширюються:

• на програми, запущені від імені облікового запису SYSTEM;

• драйвери та інші додатки рівня ядра;

• макроси всередині документів Microsoft Office;

• програми, написані для загальної багатомовною бібліотеки часу виконання (Common Language Runtime).

Отже, процеси від SYSTEM не контролюються. Перший фінт вухами: якщо є доступ до якогось ПО, запущеного під такою учеткой, - атакуємо. Наприклад, натискаємо Win + U - запускаються «доступного режиму» (лупа і екранна клавіатура). Utilman.exe (процес «спеціальних можливостей») при цьому запускається від SYSTEM. Далі йдемо там в «Довідку». Вона теж повинна відкритися з потрібними привілеями, так як запущена в контексті процесу c правами SYSTEM. Якщо вінда не найновіша (до Vista), то натискаємо правою кнопкою на синій верхній панелі «Jump to url», там друкуємо «C:» і отримуємо справжній вбудований explorer. Якщо новіша, то можна по правому кліку в тексті хелпа переглянути вихідний код (View Source) через блокнот, звідки далі дістатися до файлів. Або інший варіант - «додати» новий принтер, отримавши знову ж доступ до лістингу файлів.

Інша цікава категорія - макроси всередині документів Microsoft Office. Це страшна справа. Спробуємо для початку реалізувати запуск ПО. Хоча якщо запуск заблочен звичайними політиками (Не SRP), як, наприклад, блокуванням диспетчера задач, то цей обхід не спрацює. Але нам-то головне - запустити спеціальний exe'шнік. Тому в будь-якому документі сміливо створюємо наступний макрос і пробуємо запустити його:

Sub GOSHELL ()
Shell "C: windowssystem32regedit.exe", vbNormalFocus
End Sub

В результаті, як ти можеш здогадатися, ми отримуємо запущений exe. Хардконний метод запропонував знову ж Дідьє Стівенс . Використовуючи в макросі MS Excel функції VirtualAlloc, WriteProcessMemory і CreateThread, він зумів довантажити шеллкод з макросу в пам'ять процесу. Даний шеллкод підвантажує DLL'ку в пам'ять процесу, а DLL'ка - не що інше, як cmd.exe. До речі, її вихідні коди взяті з проекту ReactOS. Як я вже сказав, SRP може перешкоджати запуску DLL'ек (хоча і не робить цього за замовчуванням), але якщо подгрузку бібліотек здійснювати, використовуючи функцію LoadLibraryEx з LOAD_IGNORE_CODE_AUTHZ_LEVEL замість LoadLibrary, то перевірка на приналежність довантажувати dll до white-листу не відбувається!

Трюк 6. Використовуємо змінні середовища

Коли починаєш мучити групові політики, то приходить усвідомлення, що для створення захищеної системи буде потрібно попотіти. Справа важка і з великою кількістю тонкощів. Наприклад, розробники пропонують адмінам використовувати зручний хинт - вказувати змінні середовища в якості шляхів для обмежень SRP. Так ось тут проблема. У користувача, якщо їх жорстко не прищучити, є можливість їх перевизначати. Вказав, наприклад, адмін, що з папки% TEMP% можна запускати exe'шнікі, а юзер взяв та й перевизначив наступною командою:

Set TEMP C:

І ось так просто отримав можливість запускати файли з кореня C :. Крім того, не варто забувати про стандартні директорії, з яких дозволений запуск exe-файлів:

• % HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%

• % HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot% *. Exe

• % HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot% System32 * .exe

• % HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionProgramFilesDir%

Вони дозволяють використання програмного продукту тільки з папки Windows і Program Files для користувачів. У звичайного користувача немає можливості запису в них, але і тут можуть бути проблеми. Так як насправді права на запис у користувача є - по дефолту в папку C: windowssystem32spoolPrinters і C: windowstemp. Якщо у користувача буде можливість писати в якийсь каталог з софтом, то, вважай, відповідні політики SRP вже не спрацюють. До речі, для того щоб на практиці повірити, які користувач має права, допоможе тулза - AccessChk від все того ж Руссиновича .

Трюк 7. Використовуємо іншого користувача

Є спосіб не підпустити подгрузки політик, але для цього трику нам знадобляться логін і пароль іншого користувача. Суть в тому, що нам треба ввійти в систему «ще раз», але не під собою. Тут два варіанти:

1. <Shift> + правий клік на запускається файлі, далі в контекстному меню вибираємо «Run as ...».

2. Через консоль набираємо команду: runas / noprofile <назва exe-файлу>.

Інший користувач, під яким ти запускаєш програму, як і ти, може бути звичайним користувачем з обмеженими правами. Але політики на запущену програму вже не будуть діяти! Див. Малюнок.

На ньому користувач test_gpo3 не може запустити regedit через політик. Але, запустивши під test_gpo2 будь exe'шнік (диспетчер задач наприклад), він уже нічим не обмежений і тому може запустити regedit. Крім того, якщо у нас є можливість віддаленого входу в систему (по RDP, наприклад), то ми можемо провести аналогічний фінт, але тільки з однією учеткой (демонстрацію можеш подивитися в це відео ).

Трюк 8. Згадуємо про HTA

Останній хинт стосується неофіційних винятків, на які не діють групові політики. Вадімc Поданс написав в блозі відмінну серію постів, присвяченій SRP-політикам. Зокрема, він виявив відмінний шлях для їх обходу і змогу виконувати довільний код з використанням програми HTA (HTML Application).

Отже, послідовність дій:

1. Створюємо файлик з приблизно таким текстом:

   <HTML>
   <Script language = "vbscript"> msgbox "I'm dangerous VB Code !!!" </ script>
   </ HTML>

2. Зберігаємо його з розширенням .hta (наприклад, execute_this.hta).

3. Створюємо ярлик для нього.

4. Відкриваємо посилання - і hta запускається.

Чи треба говорити, що замість виклику нешкідливого MessageBox'а VB-код може зробити в системі що завгодно? Політики SRP повинні перевіряти весь код, який може виконуватися, в тому числі і всілякі скрипти. Однак через тонкощів роботи групових політик даний обхід працює. До аналогічних «глюковатим» розширень крім HTA Вадімс відносить REG, MSC, HTA, CHM. Точно так же ситуація спостерігається і з com-файлами (в тому числі всякими олдскульний ДОС'овскімі програмами, які все ще розкидані в папці вінди). Вони не враховують правила групових політик, так як працюють у віртуальній машині DOS.

Групові політики в тонких клієнтах

Хочеться ще розповісти про такі системи, як Citrix XenApp. Що це таке? XenApp, якщо говорити простою мовою, це система «доставки» додатків (хоча це тільки частина функціоналу). По суті, це щось типу термінального сервера вінди, але коли користувачеві доступний тільки конкретне застосування. У житті це виглядає так. Користувач коннектітся клієнтом до Citrix-сервера - йому виводиться список доступного ПО. Далі користувач запускає якийсь додаток і починає в ньому працювати. Основна фіча в тому, що фактично процес додатки виконується на Citrix-сервері. По суті, даний підхід хороший (особливо з тонкими клієнтами), але у нього є пучок косяків з точки зору безпеки. Так як процес - на сервері, то, значить, користувачеві доступні всі ресурси сервера (з урахуванням призначених для користувача прав, звичайно). Це не дуже добре, тому що передбачається, що у користувача повинен бути доступ тільки до запущеної програмі, а не до ОС. Що ще гірше, дістатися-то до самої ОС - не проблема. Навіть якщо у самого ПО немає можливості по взаємодії з ОС (немає меню «Відкрити», «Зберегти як»), то стандартні можливості вінди все ще працюють: натискаємо в Citrix-додатку <Ctrl + Shift + Esc> - нам відкривається диспетчер задач Citrix -сервера, або правий клік по розкладці клавіатури, а звідти в файл довідки з можливістю лістингу директорій. Особисто я зіткнувся з груповими політиками саме в цьому контексті - при зломі Citrix.

наш підсумок

Як ти можеш помітити, всіляких лазівок повно. Їх різноманітність і хитрощі не можуть не дивувати. Те, що я скажу далі, може тебе здивувати. Навіть після перерахування всіх цих способів для обходу обмежень я все ж настійно рекомендую не нехтувати їх використанням. До того ж тепер ти можеш враховувати можливість застосування цих лазівок і з набагато більшою ймовірністю налаштувати систему, яка буде достатньо захищена.