Підвищення привілеїв у Windows-середовищі

Практика управління інформаційною безпекою: pentest

Підвищення привілеїв користувача до рівня адміністратора домену Windows

Введення

Хороша система управління інформаційною безпекою (СУІБ) вимагає регулярної оцінки своєї ефективності. Існують різні методики подібних оцінок, одним з різновидів яких є т. н. «тест на проникнення» або pentest – санкціонована симуляція хакерської атаки на інформаційну систему з метою виявлення вразливостей в її захист до того, як їх виявить реальний зловмисник. При цьому можуть використовуватися будь-які доступні у реальному житті хакерські інструменти, експлойти, методи і т. д.

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

Опис об’єкта тестування

Об’єкт тестування досить стандартний – інформаційна система невеликий (менше 200 співробітників) компанії, що спеціалізується на розробці ПЗ. Внутрішня мережа компанії також типова: комутований Gigabit Ethernet, домен Microsoft Windows (будемо називати його CORP.LOCAL). Внутрішні хости розділені на IP – підмережі на підставі своєї функціональної належності (як то: група розробників, інженери з якості, відділ управління кадрами, бухгалтерія, маркетинг, топ-менеджемент, facilities і т. д.), вся сегментація зроблена на L3-комутаторі. Також є виділений в окрему IP-підмережі парк внутрішніх серверів, що містить: два контролера домену Windows Server 2008 з інтегрованою DNS, внутрішній поштовий сервер під керуванням Exchange, файл-сервер, термінальний сервер і деякі інші допоміжні сервера під керуванням Windows і Linux. Окремо варто відзначити тестову лабораторію з парком машин під управлінням різних версій Microsoft Windows (як десктопних, так і серверних) і призначених для тестування розроблюваного ПЗ. Доступ до хостам тестовій лабораторії мають усі працівники. Основна версія настільної ОС – Windows 7. На настільних комп’ютерах і серверах встановлено погано налаштоване антивірусне ПО різних виробників (від компаній Symantec, Mcafee і Trend Micro, чому погано налаштоване – про це пізніше).

Модель порушника

Порушник – внутрішній співробітник, який має непривілегійований обліковий запис домену, настільний комп’ютер, фізичний доступ до тестових комп’ютерів, (можливо, має корпоративний ноутбук), але не має ні на одному з них привілеїв адміністратора. Обліковий запис порушника не має можливості змінювати налаштування антивірусного ПО. Мета порушника – отримати доступ, еквівалентний доступу адміністратора, до контролеру домену та/або файлового сервера.

Як бачимо, і модель порушника, та опис компанії досить типово.

Реалізація атаки

Крок 0. Збір інформації про внутрішню мережу

Отже, ми діємо від особи порушника. На даному кроці нам потрібно зібрати інформацію про:

  • внутрішню адресацію і розбиття на підмережі
  • імена і IP-адреси хостів, в першу чергу нас цікавить список серверів
  • використання протоколу NetBIOS.

Спочатку за допомогою утиліти ipconfig ми отримуємо IP-адреси серверів DNS:192.168.12.1 і 192.168.12.2. Т. к. служба DNS інтегрована з Active Directory, це дає нам підстави вважати, що ми знаємо IP-адреси контролерів домену. Далі використовуючи утиліту nslookup в інтерактивному режимі ми намагаємося отримати список всіх хостів в зоні corp.local:

> ls –d corp.local > file

Фактично, ця команда ініціює повний трансфер зони DNS, із збереженням її у файл. Багато адміністраторів забувають налаштувати обмеження на трансфер зони для внутрішньої мережі, чим полегшують потенційному зловмиснику збирання відомостей про інфраструктуру компанії, детальніше див. [12].

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

Крок 1. Отримання привілеїв локального адміністратора

Теорія. Для отримання пароля локального адміністратора застосовується атака на збережене в системному реєстрі значення хеш-функції цього пароля. Незважаючи на те, що математично хеш-функція є незворотною, обчислення пароля можливо шляхом прямого перебору її значень спільно з атакою по словнику. У Windows історично застосовується два алгоритму обчислення захищений хеш-функції: застарілий алгоритм LM і більш новий алгоритм NT (іноді також званий NTLM). Хеш-функція LM є вразливою в силу своєї малої обчислювальної складності, що робить можливим перебір її значень навіть на слабкому комп’ютері. Наявність у реєстрі системи одночасно LM – і NT-хеш пароля гарантують зловмиснику його зламати за прийнятний час. Значення хеш-LM при налаштуваннях за замовчуванням зберігається в реєстрі ОС Windows XP/2003, що робить ці системи особливо привабливими для хакера. Хеш-функція NT є обчислювально більш складною, однак, перебір її значень значно спрощується тим, що для неї існують доступні таблиці pre-calculated значень (т. зв. Rainbow-таблиці) – вони зводять обчислення значення хеш-функції до пошуку потрібного хеша серед pre-calculated значень.

Читайте також  Вивчаємо інтернет-маркетинг самостійно: понад 50 безкоштовних курсів

Об’єкт атаки. Хеші паролів в базі SAM (реєстр). У нашому випадку це всі машини, до яких ми маємо фізичний доступ. В першу чергу, це наш робочий десктоп, у другу – хости для виконання тестів.

Реалізація. З машинами, яким є фізичний доступ, проробляємо наступну операцію: завантажуємося з зовнішнього носія (використовуючи Windows Pre-installation Environment CD або Linux Live CD), монтуємо системний розділ NTFS і копіюємо гілки реєстру HKLMSYSTEM і HKLMSAM (файли %WINDIR%System32ConfigSystem %WINDIR%System32ConfigSam відповідно). Особливу увагу приділяємо машинах під управлінням Windows XPWindows 2003, на яких імовірно знаходження LM-хеша. Для дампа паролів з скопійованих файлів реєстру використовуємо використовуємо інструменти [1], [2] (посилання в кінці статті). Результат:

Останній рядок містить шуканий NT-хеш локального адміністратора. На хостах з тестової лабораторії (назвемо ці хости LAB1 і LAB2) знаходимо ненульовий LM-хеш:

Отже, нами отримані NT – і LM-хеші. Але як відновити з них пароль? Для цього скористаємося тими ж інструментами [1], [2] а також онлайн сервісами реверсу хеша [8] — [11]:

Примітка: реальний пароль складався з назви компанії з невеликим модифікатором і швидко зламався під атакою по словнику).

Результат. Успіх. Отримані паролі (нехай вони будуть «Pa$$word1» і «Pa$$word2») облікового запису локального адміністратора з нашого робочого десктопа і двох тестових комп’ютерів. Але чи допоможуть вони отримати права адміністратора домену? Про це далі.

Крок 2. Отримання облікових даних адміністратора домену

Теорія. У більшості випадків для цього достатньо отримати значення NT-хеш пароля адміністратора домену. Це пов’язано з тим, що при перевірці користувача по протоколу NTLM аутентифіуаційна система пред’являє аутентификатору тільки NT-хеш, а перевірки пароля не відбувається. NT-хеш може бути отриманий з т. зв. сховища LSA шляхом звернення до т. зв. Logon-сесії адміністратора (Logon-сесія — спеціальної область даних, створювана процесом Winlogon, де зберігається ім’я користувача, домен входу і значення NT-хеш пароля, все разом це називається LSA-secret). Цей NT-хеш використовується процесом NTLMSSP при аутентифікації по протоколу NTLM. Logon-сесія зберігається весь час поки обліковий запис залогінений в систему. Також NT-хеш можна перехопити з NTLM-сесії аутентифікації адміністратора. Крім того, отримання пароля адміністратора можливо з кешу Domain Cached Credentials (DCC). DCC — це локальний кеш, який заповнюється при успішному вході користувача в домен. Призначення кешу DCC — мати можливість провести аутентифікацію користувача при недоступності контролера домену.

Об’єкти атаки:

  • Хеші DCC (гілка реєстру HKLMSecurity).
  • Logon-сесія адміністратора домену (LSA-secret).
  • Перехоплення NTLM-сесії (не розглядаємо з-за більшої практичної складності).

Практика. Багато Windows-адміністраторів для виконання різного роду операцій на комп’ютерах користувачів використовують обліковий запис адміністратор домену. При цьому його дані потрапляють в кеш DCC. Тому спочатку спробуємо отримати пароль з кешу DCC. Заходимо на нашу робочу станцію, зберігаємо гілку реєстру HKLMSecurity і імпортуємо її в [1]. Оскільки у нас є пароль локального адміністратора, завантажувати машину з зовнішнього носія для збереження реєстру вже не потрібно:

У кеші лежать дані паролів трьох облікових записів. Останній обліковий запис (***user) нас не цікавить, другий обліковий запис шуканих привілеїв не має, а ось користувач shadmin схожий на шуканого адміністратора. На жаль, алгоритм MS-CACHE2 має велику обчислювальну складність і атака прямим перебором на нього неефективна. Функція MS-CACHEv2 містить “обчислювальний секрет” — salt (в якості “salt” використовується ім’я облікового запису) що робить її захищеною від атаки по Rainbow-таблиць. Проте, в майбутньому можлива поява таблиць значень хеш для стандартних облікових записів – “Administrator”, “Адміністратор” і т. д. Заради інтересу відправляємо знайдений “кеш-хеш” в хмарний сервіс [8] — [11] (про результати й ефективність таких сервісів в кінці статті). Поки «хмара думає» намагаємося знайти інші DCC. Аналізуємо список хостів, отриманий на кроці 0, перевіряємо, на які сервера ми можемо зайти під локальним адміністратором використовуючи паролі, отримані на кроці 1. Т. к., на контролері домену локальний адміністратор заблокований, а поштовий сервер зазвичай краще захищений, експериментувати треба з другорядними серверами. У нашому випадку В списку серверів був знайдений сервер з непримітним ім’ям Upd. Вхід з знайденим на кроці 1 паролем “Pa$$word2” виявляється успішним. Виявляємо, що на хості Upd:

  1. Не встановлено антивірусне ПО.
  2. На ньому працює Apache, який є сервером корпоративного управління для антивіруса (це означає, що там є пароль облікового запису, що використовується для віддаленого встановлення антивірусного ПО і теоретично його можна звідти витягнути).
  3. На хості не ведеться аудит невдалих спроб входу.
  4. ОС Windows 2008 R2.
Читайте також  Створення 1k intro Chaos для ZX-Spectrum

Зробивши дамп реєстру HKLMSecurity ми отримуємо DCC-хеш облікового запису СORP.LOCALAdministrator (і ряду інших):

Теоретично, можна спробувати підібрати пароль до Administrator через хмарний сервіс. Однак, як я вже згадував вище, атака перебором на MS-CACHEv2 марна (хоча, можливо, через пару років ситуація зміниться). Залишаємо в спокої DCC і переходимо до пошуку Logon-сесій. Перевіряємо, хто увійшов в систему на хості Upd:

Бачимо, що на машині Upd висять дві неактивні сесії – адміністратора і вже знайомого нам користувача Shadmin, а значить, ми можемо отримати NT-хеші їх паролів шляхом крадіжки LSA-secret. Це ключовий момент, який визначив успіх всієї атаки. Для крадіжки хеша використовуємо експлойт Lslsass [3]. Для його виконання необхідні права локального адміністратора (точніше, права на налагодження процесів), які у нас вже є. Отримуємо список секретів LSA (у форматі «доменобліковий запис:LM-хеш:NT-хеш:::»):

lslsass v1.0 - Copyright (C) 2010 Bjorn Brolin, Truesec (www.truesec.com)
Found Lsass pid: 520
Lsass process open
Found possible primary token
Found real token
UPDAdministrator::00000000000000000000000000000000:<i>8833c58febc977799520e7536bb2011e</i>:::
Found possible primary token
Found possible primary token
Found possible primary token
Found real token
UPDAdministrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e:::
Found possible primary token
Found real token
UPDAdministrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e:::
Found possible primary token
Found real token
CORP.LOCALUPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b:::
Found possible primary token
Found real token
CORP.LOCAL UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b:::
Found possible primary token
Found real token
CORP.LOCAL UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b:::
Found possible primary token
Found real token
CORP.LOCAL Administrator::00000000000000000000000000000000:<b>c690e441dc78bc5da8b389e78daa6392</b>:::
Found possible primary token
Found real token
CORP.LOCAL shadmin::00000000000000000000000000000000:<b>5794cba8b464364eacf366063ff70e78</b>:::

Виділені болдом рядки містять шукані парольні хеші. Також зверніть увагу на виділений курсивом хеш в шостій сходинці. Де-то ми його вже бачили, правда?

Результат. Успіх. У нас на руках NT-хеш пароля облікового запису адміністратора домену. Але яка користь від хеша, якщо відновлення вихідного пароля по ньому за прийнятний час неможливо? Про це в наступному кроці.

Крок 3. Обманюємо NTLM-аутентифікації сесію

Теорія. Windows ніколи не використовує для аутентифікації пароль в чистому вигляді, аутентифікована система завжди пред’являє хеш. Звідси виникає ідея: замінивши ім’я користувача, домен входу і NT-хеш в Logon-сесії зайшов в систему користувача на відповідні значення доменного адміністратора ми можемо аутентифікуватися по протоколу NTLM за віддаленою системою як адміністратор домену. Дана атака [7] можлива тільки при аутентифікації по протоколу NTLM. Незважаючи на широке поширення протоколу Kerberos, NTLM є єдиним можливим способом аутентифікації клієнта, при доступі до мережевого шару не по символьному імені, а за IP-адресою [13].

Об’єкт атаки. Logon-сесія локального адміністратора.

Практика. Існує декілька доступних експлойтів, що дозволяють реалізувати атаку на платформі Windows Server 2008 x86 і x64. Основним є експлойт Windows Credentials Editor [4]. Для здійснення атаки заходимо на хост LAB2, використовуючи облікові дані “Administrator””Pa$$word2”. З допомогою [4] підміняємо ім’я облікового запису, домен входу і дані NT-хеш в Logon-сесії на відповідні значення Shadmin, отримані нами на попередньому кроці:

Ім’я облікового запису адміністратора домену та її NT – хеш передається команді wce як аргумент командного рядка. Результат — хеш успішно змінено. Зауважу, що членство користувача в групі і токен доступу при атаці не змінюються:

Ми як і раніше локальний Administrator, замазане зеленим ім’я хоста на скріншоті вище — LAB2. Однак, при NTLM-аутентифікації віддаленої систему буде пред’явлено ім’я домену CORP.LOCAL, ім’я користувача Shadmin і хеш від пароля Shadmin. Ось дамп одного мережевого пакету, що містить security blob сесії NTLM:

Замазано зеленим ім’я домену (CORP.LOCAL) і ім’я хоста (LAB2 ) ), пред’явлений обліковий запис – Shadmin. Тепер намагаємося підключитися до кореневого розділу системного тому на контролері домену командою net use використовуючи IP-адресу контролера домену:

Успішно. Для перевірки доступу я створив докорінно текстовий файлик (знайдіть його на скріншоті). Створивши на диску контролера домену батник з потрібної нам послідовністю команд, ми можемо, використовуючи [5], виконати на контролері домену потрібну операцію (наприклад, додати користувача до групи адміністраторів домену). Операція буде виконана з правами облікового запису Shadmin. Для ілюстрації створюємо на віддаленому хості простий командний файл, додати локального користувача:

net user TstUsr Pa$$word /add

Віддалено запускаємо його з хоста LAB2:

Він буде виконаний у віддаленій системі 192.168.13.125 з привілеями користувача нашої поточної сесії – shadmin (тобто, адміністратора домену). Перевіряємо:

Другий вивід команди net user показує нового користувача. Незважаючи на неможливість запуску таким чином додатків, що вимагають інтерактивної взаємодії з користувачем (наприклад, оснастки MMC), можна виконати широкий спектр дій за допомогою скриптів.

Результат. Успіх. Отриманий доступ до файлової системи і shell контролера домену.

Резюме

Коротко ланцюжок атаки виглядала наступним чином: Збір інформації про структуру мережі -> Отримання пароля локального адміністратора -> Використання цього пароля для входу на один з другорядних серверів -> Крадіжка «залишених без нагляду» облікових даних адміністратора домена -> Модифікація своєї Logon-сесії та підвищення привілеїв до потрібного рівня.

Читайте також  Дані користувачів Windows на ПК з підтримкою сенсорного введення пишуться в окремий файл

Успіху атаки сприяли:

  1. Слабкий захист зони DNS від трансферу на недоверенные хости.
  2. Слабка парольна політика. На більшості комп’ютерів домену для облікового запису локального адміністратора використовувався однаковий пароль, уразливий до атаки по словнику.
  3. Відсутність або слабке налаштування антивірусного ПЗ на критичних хостах.
  4. Слабкий захист пральних хешей – дві неактивні адміністраторські Logon-сесії на хості Upd, наявність хешей LM бази SAM.
  5. Незадовільна політика аудиту.

На підставі цього можна вивести загальні рекомендації по захисту:

0. Ретельно приховувати внутрішню структуру мережі від можливих зловмисників. Так, у користувачів не повинно бути можливості отримати повний вміст файлу зони DNS. Недовірених користувачів (це можуть бути, наприклад, стажисти, працівники, у яких не закінчився випробувальний термін і т. д.) має сенс переносити в окрему підмережу, використовуючи NAT для підміни адрес (включаючи, наприклад, модифікацію DNS-відповідей).

1. Правильна політика призначення пароля локального адміністратора. Пароль локального адміністратора має бути різним на хостах, що мають різну ступінь захищеності від НСД. Компрометація пароля локального адміністратора на будь-якому з хостів домену повинна зводити до мінімуму можливість використання цього пароля зловмисником.

2. Зберігання LM-хеша в SAM повинно бути заборонено політиками безпеки.

3. Не треба використовувати в якості частини пароля адміністратора назву компанії або її домену ) Це утруднить зловмиснику атаку за словником. Але навіть використовуючи складний пароль, не забувайте самостійно і регулярно перевіряти його хеш на стійкість, використовуючи онлайн-сервіси.

4. Не рекомендується виконувати рутинні операції на комп’ютерах домену з-під облікового запису адміністратора домену. Це захистить обліковий запис від перехоплення даних Logon-сесії та від потрапляння хеш пароля в DCC-кеш.

5. Взяти за правило не залишати без нагляду Logon-сесію адміністратора домену. Best practice: закінчив роботу – разлогінся.

6. Утиліти підміни LSA досить нечисленні. Має сенс простежити їх еволюцію та перевіряти їх успішне детектування корпоративним антивірусним ПЗ.

7. У користувача, що навіть має права локального адміністратора, не повинно бути можливості змінювати налаштування корпоративного антивіруса. Вимкнення служби антивіруса на робочих станціях домену повинно призводити до оповіщення адміністратора домену (в цьому сенсі в ході тесту непогано відпрацював Symantec Endpoint Protection).

Додаток 1. Поведінка антивірусного ПЗ

На комп’ютерах компанії використовувалося антивірусне трьох видів: KAV, актуальний на момент проведення тесту Symantec Endpoint Protection і застарілий продукт від Trend Micro. У більшості випадків використані в ході атаки інструменти визначалися як Hack Tool/Rootkit/Trojan. KAV без попередження видаляв їх, а SEP (навіть вимкнений) видавав попередження і переміщав в карантин не даючи можливості запустити. Однак наявність прав адміністратора дозволяє відключити KAV, а захист SEP була обійдена шляхом ручного прописування шляху-виключення для перевірки, знову-таки, з використанням облікового запису локального адміністратора. Встановлений на деяких хостах антивірус від Trend Micro не запуск експлойтів реагував ніяк.

Додаток 2. Ефективність використання онлайн-сервісів перевірки хеша

Для перевірки стійкості хешей паролів існує безліч онлайн-сервісів. Вони дозволяють працювати з найбільш поширеними хэшами – LM, NTLM, MD4, MD5, WPA, з хэшами, використовують salt і т. д. Для перевірки хеша використовується прямий перебір з використанням обчислювальної потужності сучасних GPU, перебір за словником, гібридні атаки і т. д. Раз розкритий хеш може поповнити базу і використовуватися надалі. Сервіс може бути безкоштовним для перевірки короткого (не менше 8 символів) паролю або брати невелику винагороду. В процесі тесту я використовував чотири таких сервісу, посилання наведені в кінці статті. Я відправив кілька знайдених на кроці 2 хешей і через 15 місяців отримав від сервісу On-line Hash Crack [9] повідомлення про успішне відновлення одного з них )

Посилання

Використані інструменти

[1] Cain & Abel — a password recovery tool for Microsoft Operating Systems. It allows easy recovery of several kind of passwords by sniffing the network, cracking encrypted passwords using Dictionary, Brute-Force and Криптоаналіз attacks, recording VoIP conversations, decoding scrambled passwords, recovering wireless network keys, revealing password boxes, uncovering cached passwords and analyzing routing protocols.
[2] L0pht Crack.
[3] Lslsass exploit. Dumps active logon session password hashes from the lsass process.
[4] Windows Credentials Editor post-exploit. Інструмент для зміни Logon-credentials.
[5] PsExec з комплекту PC Tools

Докладні описи вразливостей

[6] Серія статей «Ефективне отримання хеш пароля в Windows» на сайті www.securitylab.ru
[7] Pass-the-Hash, опис атаки на віддалену систему шляхом надання їй скомпроментированного хеша.

Хмарні сервіси злому хешей
[8] Question-defense.com (здається, вже непрацездатний на момент публікації ( )
[9] www.onlinehashcrack.com
[10] www.cloudcracker.com
[11] On-line hash killer

Додаткові матеріали

[12] Безпека і тюнінг DNS в Windows Server
[13] Kerberos is not used when you connect to SMB shares by using IP address

Степан Лютий

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

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *