День 7. Metasploit Framework 3 и неудачная разработка эксплойта

Метки: Kali Linux, Metasploit, msfpescan, Windows, Эксплойты

За сегодня разобрался с зависимостями модулей в Metasploit Framework 3 и начал пробовать разрабатывать эксплойты (пока безуспешно). Чтобы продолжить эту тему, необходимо разобраться с Ruby, реверс-инжинирингом, программой ImmunityDebugger (которая позднее будет использоваться) и много с чем другим.

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

Вчера я начал учиться разрабатывать эксплойты. В папке Metasploit-framework нашел гайд (к сожалению, 2007 года) на 78 страниц. Название его следующие: Metasploit 3.0 Developer’s Guide.

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

Раздел «Chapter 1». Metasploit 3.0 Developer’s Guide

Сотрудников Metasploit постоянно спрашивали, почему используется Ruby. В этом разделе они отвечают. Во-первых, они так захотели, потому что он им нравится. О является как простым, так и мощным интерпретируемым языком. Во-вторых, его поддержка многопоточности не зависит от платформы. Далее они нахваливают язык Ruby.

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

Язык C++ не выбрали из-за его сложности как языка, так и переносимости (так как он является компилируемым языком, а не интерпретируемым).

Теперь об архитектуре (или структуре) платформы Metasploit. Наиболее фундаментальной частью архитектуры является библиотека Rex (это сокращение от Ruby ExtensionLibrary1). Сам Rex разработан так, чтобы не иметь никаких зависимостей, кроме тех, которые поставляются вместе с Ruby по умолчанию. Кстати, на рисунке 1 представлены зависимости.

Рис. 1. Зависимости фреймворка Metasploit

Далее идет Framework Core. Ядро фреймворка отвечает за реализацию всех необходимый интерфейсов, позволяющих взаимодействовать с модулями эксплойтов, сессиями и плагинами.

Эта библиотека расширена Framework Base. Она предназначена для предоставления более простых процедур-оболочек для работы с ядром фреймворка, а также предоставляет служебные классы для работы с различными аспектами фреймворка.

Framework Base расширяется пользовательским интерфейсом, т.е. командная строка и веб-интерфейс. А также расширяется модулями и плагинами.

Framework Modules определяется как эксплойт, полезная нагрузка, кодировщик, генератор NOP или вспомогательный (auxiliary) модуль.

Framework Plugins определяется как что-то, что расширяет функциональность фреймворка или заставляет существующую функцию работать по другому (переопределять). Теперь возвращаюсь к сайту Offensive Security, чтобы продолжить учиться разрабатывать эксплойты. Так и буду чередовать.

Раздел «EXPLOIT MODULE FORMAT» (Формат эксплойт-модуля)

Скопировал пример, создал файл my_explot.rb и запустил msfconsole. Количество эксплойтов не увеличилось. Начал сравнивать пример на сайте и пример из документации. Разница большая.

Пришлось переписать пример с сайта по аналогии с примером эксплойта, который я нашел вчера. Вот конечный результат:

class MetasploitModule < Msf::Exploit::Remote
	Rank = NormalRanking

	include Exploit::Remote::Tcp

	def initialize(info = {})
    		super(
      			update_info(
        			info,
        			'Name' => 'Simplified Exploit Module',
        			'Description' => %q(
            			This module sends a payload
       				 ),
        			'Author' => ['skape'],
        			'Payload' => { 'Space' => 1024, 'BadChars' => "\x00" },
        			'Targets' => [ ['Automatic', {} ] ],
        			'Platform' => 'win',
				)
			)
    		register_options( [
				Opt::RPORT(12345)
			], self.class)
	end

	# Connect to port, send the payload, handle it, disconnect
	def exploit
		connect()
		sock.put(payload.encoded)
		handler
		disconnect()
	end
end

В данном примере не используется метод check, то есть проверка доступности эксплойта не работает. Метод check() проверяет все параметры, кроме полезной нагрузки. Цель проверки, как было сказано раньше, определить, уязвима цель или нет. Метод check() возвращает определенное значение:

CheckCode::Safe — нельзя использовать
CheckCode::Detected — служба обнаружена
CheckCode::Appears — уязвимая версия
CheckCode::Vulnerable – подтверждено
CheckCode::Unsupported — проверка не поддерживается для этого модуля.

Далее в эксплойт я добавил метод check():

def check
			# connect to get the FTP banner
			connect

			# grab banner
			banner = banner = sock.get_once

			# disconnect since have cached it as self.banner
			disconnect
		
		 	case banner
				when /Serv-U FTP Server v4\.1/
					print_status('Found version 4.1.0.3, exploitable')
					return Exploit::CheckCode::Vulnerable

				when /Serv-U FTP Server/
					print_status('Found an unknown version, try it!');
					return Exploit::CheckCode::Detected

				else
					print_status('We could not recognize the server banner')
		            return Exploit::CheckCode::Safe
		end

		return Exploit::CheckCode::Safe
	end

Переходим к разделу «EXPLOIT MIXINS». (Примеси эксплойтов).

Модуль Exploit::Remote::Tcp

В этом модуле:

Определяется RHOST, RPORT, ConnectTimeout
Обеспечивает connect(), disconnect()
Создает self.sock как глобальный сокет
Предлагает SSL, прокси, CPORT, CHOST
Уклонение с помощью отправки малого сегмента
Уклонение с помощью отправки малого сегмента

Модуль Exploit::Remote::DCERPC

Унаследован от миксина (т.е. примесь – элемент языка программирования, реализующий какое-либо четко выделенное поведение) TCP и имеет следующие методы и параметры:

dcerpc_handle()
dcerpc_bind()
dcerpc_call()
Поддерживает методы обхода IPS с многоконтекстными запросами BIND и фрагментированными вызовами DCERPC.

Модуль Exploit::Remote::SMB

smb_login()
smb_create()
smb_peer_os()
Предоставляет параметры SMBUser, SMBPass и SMBDomain.
Выявляет методы обхода IPS, такие как: SMB::pipe_evasion, SMB::pad_data_level, SMB::file_data_level

Модуль Exploit::Remote::BruteTargets

Вызывает brute_exploit() для каждого шага
Легкий перебор и диапазон адресов

Перечисленные выше примеси – это лишь верхушка айсберга. Например, есть и другие:

Capture – захват сетевых пакетов
Lorcon – отправка необработанных кадров WiFi
MSSQL – взаимодействие с серверами Microsoft SQL
KernelMode – использование ошибок ядра
SEH – структурированная обработка исключений
NDMP – сетевой протокол резервного копирования
EggHunter – поиск по памяти
FTP – работа с FTP-серверами
FTPServer – создание FTP сервера

Подводя итог, в этом разделе просто перечислены возможности.

Раздел «EXPLOIT TARGETS» (Цели эксплойтов)

Эксплойты определяют список целей, которые включают имя, номер и параметры. Далее пример кода:

'Targets' => [
                 		# Windows 2000 – TARGET = 0
                		[
							'Windows 2000 English',
							{ 'Rets' => [ 0x773242e0 ], },
						],
                 		# Windows XP - TARGET = 1
                 		[
							'Windows XP English',
							{ 'Rets' => [ 0x7449bf1a ], },
						],              
          			],
          			'DefaultTarget' => 0,

До этого у меня было написано:

'Targets' => [ ['Automatic', {} ] ],

Ранее цель определялась автоматически. Теперь есть конкретные две цели: Windows 2000 и Windows XP. В блоке конкретной цели возможно использование произвольной формы (как я понимаю, речь идет об этом блоке { 'Rets' => [ 0x773242e0 ], }), хотя есть некоторые специальные имена параметров.

Параметр Ret – сокращение от terget.ret() – исчерпывающие объяснение. На GitHub в реализации класса (https://github.com/rapid7/metasploit-framework/blob/master/lib/msf/core/module/target.rb#L311) можно найти следующие комментарий: Ret – целевой обратный адрес или адреса, которые будут использоваться.

В целях хранятся, например:

Обратный адрес для цели Windows 2000;
Для целей Windows XP необходимо добавить 500 байт заполнения;
Обходной адрес Windows Vista NX.

Далее про доступ к информации о цели. Целевой (Target) объект внутри эксплойта – это выбранная пользователем цель, и доступ к нему осуществляется в виде хэша:

target[‘padcount’]
target[‘Rets’][0]
target[‘Payload’][‘BadChars’]
target[‘opnum’]

К чему вышеперечисленные примеры вообще не понятно. Далее про добавление и исправление целей эксплойта. Иногда нам нужны новые цели, потому что конкретный языковой пакет меняет адреса, доступна другая версия программного обеспечения или изменены адреса из-за хуков (сколько тонкостей, которые не входят в курс по Metasploit). Чтобы добавить новую цель, необходимо выполнить три шага:

Определить требуемый тип обратного адреса. Это может быть переход к определенному регистру или еще что-то. Комментарии в коде эксплойта могут помочь определить, что требуется. Далее необходимо получить копию целевых двоичных файлов. И последний шаг: использовать msfpescan, чтобы найти подходящий обратный адрес. До сих пор не могу понять, что понимается в этом контексте под обратным адресом. Пока искал это и как использовать msfpescan, натолкнулся на книгу Джеймса С. Фостера «Техника взлома: сокеты, эксплойты, shell-код». Оставлю ее на потом, думаю, там можно найти много интересного, несмотря на ее возраст (2006 год издания).

Следующий подраздел, получение обратного адреса с помощью msfpescan. Я не дочитал и начал искать про него. Зато нашел книгу. Итак, если код эксплойта явно не говорит нам (а мне вообще ничего не говорит), какой тип адреса возврата требуется, но в нем указано имя dll для существующего эксплойта, то можно узнать, какой тип адреса возврата мы ищем. Рассмотрим следующий пример, предоставляющий обратный адрес для цели Windows 2000 SP0-SP4.

‘Windows 2000 SP0-SP4', { 'Ret' => 0x767a38f6, } # umpnpmgr.dll

Сразу возник вопрос. Отличие ключей (если в Ruby это называется ключами) Ret и Rets. Далее, по всей видимости, необходимо установить Windows 2000.

Далее я скачал DLL библиотеку umpnpmgr.dll. И запустил команду:

msf6 > msfpescan -D -a 0x767a38f6 umpnpmgr.dll

Никаких объяснений, что за адрес 0x767a38f6 мы используем и откуда он взялся. Результатом выполнения этой команды является ассемблеровский код (как я думаю, так как ассемблер не знаю).

Теперь необходимо использовать копию целевой DLL и использовать msfpescan, чтобы найти подходящий адрес pop/pop/ret. Загуглил про pop/pop/ret. Это из реверсинга. Кратко говоря, это какие-то указатели. Начинает немного проясняться. Далее находим нужный адрес:

msf6 > msfpescan -p umpnpmgr.dll

Им оказался 0x7675285c (почему выбран последний, и последний ли нужно выбирать, не объясняется). Теперь, хотя бы, понятно откуда берется этот адрес. Если подвести краткий итог. Необходимо раздобыть образ целевой системы (той же версии), найти необходимые файлы и получить обратный адрес.

Раздел «EXPLOIT PAYLOADS» (Нагрузки эксплойта)

Становится все сложнее и сложнее понимать. Явно не хватает знаний о реверс-инжиниринге, основ Ruby и еще чего-то, пока не понял чего. Поэтому решил пропустить (на время) разделы, связанные с разработкой эксплойтов (для программ и ОС) и перейти к разделу «WEB APPLICATION EXPLOIT DEVELOPMENT» (Разработка эксплойтов для веб-приложений). Но уже завтра.