Проксирование с помощью 3proxy и SSH
Содержание
Проброс портов имеет одно маленькое ограничение: это статическая операция, и мы делаем отдельный проброс для каждой связки ip:port . Как правило, это нужно лишь на начальной стадии, чтобы обойти файрвол. Но если надо организовать более полноценный и удобный доступ в сетевой сегмент через скомпрометированную машину, используется прокси.
Проксирование с помощью 3proxy
В простых ситуациях нет ничего лучше, чем использовать 3proxy. Утилиты из этого набора программ портативные, они не требуют установки и прав администратора. Тулзы прекрасно работают как на Windows, так и на Linux и легко кросс-компилируются. Для запуска SOCKS прокси-сервера используются следующие команды (под Linux и Windows соответственно):
Для запуска HTTP connect прокси-сервера используются следующие команды (под Linux и Windows соответственно):
Если антивирус съел 3proxy, можно попробовать утилиту из набора Nmap:
Если не помогло, то переходим к SSH.
Проксирование с помощью SSH
Возвращаясь к SSH, нужно упомянуть один упущенный ранее момент. Если тебе не удалось получить привилегии root на скомпрометированной машине, сразу же возникает ряд проблем. Во-первых, мы должны знать пароль от текущей учетки, который известен далеко не всегда. Во-вторых, если SSH не запущен, то его запуск потребует прав root. Все это, к счастью, можно исправить следующим образом:
Патчим функции, отвечающие за аутентификацию:
Теперь собираем инструмент — желательно статически, чтобы избежать проблем с зависимостями:
Слегка меняем конфиг sshd_config :
Копируем и запускаем утилиту на victim:
Теперь SSH-сервер сможет работать в роли прокси-сервера без прав root и залогиниться на него мы сможем с любым паролем.
На Windows, где сервер SSH обычно отсутствует, можно использовать freeSSHd, который будет работать в роли прокси-сервера. Правда, для этого нам все же потребуются права администратора. FreeSSHd — это отличная альтернатива 3proxy и meterpreter, когда антивирус не дает запустить ничего подозрительного.
Рассмотрим типичный пример прохождения сетевого периметра. Вообразим, что получен доступ к серверу из DMZ. На такие серверы обычно пробрасываются только нужные порты, а значит, напрямую на прокси мы не подключимся. Вспоминаем про туннелирование портов:
Теперь attacker:2222 будет проброшен на victim:22 . Через этот туннель мы организуем прокси:
Если все прошло успешно, то на attacker появится SOCKS-прокси на TCP-порту 3128. По сути, это туннель внутри туннеля.
SOCKS-прокси в качестве «туннеля внутри туннеля»
Если проблем с антивирусами нет, можно воспользоваться Metasploit, это будет немного проще:
Использование прокси в пентесте
Чтобы использовать прокси на стороне атакующего, мы можем:
- указать в настройках конкретной программы адрес прокси (тут есть минус — не все приложения поддерживают прокси);
- принудительно проксировать любое приложение (это называется «соксификация»).
Соксификацию можно организовать следующей командой:
Этот вариант подходит почти для любого приложения, даже для такого, которое не поддерживает настройку прокси, так как подменяет библиотечные вызовы connect() , send() и recv() . Однако и тут есть нюансы: проксирование не поддерживают программы, генерирующие пакеты через raw-сокеты или не использующие библиотеку libc (то есть статически собранные).
Кроме того, мы можем делать прозрачное проксирование, для чего используется прокси redsocks. Для его настройки прописываем в /etc/redsocks.conf следующее:
После этого можно запустить прокси:
Теперь можем напрямую посылать пакеты в интересующую нас сеть. Iptables прозрачно для нас перехватит их и направит на redsocks, который, в свою очередь, направит пакеты непосредственно на прокси-сервер. Однако использование raw-сокетов по-прежнему недопустимо, потому что они генерируются за пределами iptables и маршрутизации.
Источник: