При проведении тестирования на проникновение после компрометации внешнего устройства или сервиса возникает необходимость дальнейших действий для получения доступа внутрь сети. После обнаружения и эксплуатации уязвимости сетевого периметра встает вопрос о развитии атаки во внутреннюю сеть, используя в качестве «точки опоры» атакованную систему, доступную извне. Задача по построению туннелей и проброса портов является достаточно актуальной как для решения упражнений в рамках курса «Корпоративные лаборатории», так и при поведении тестирования на проникновение информационных систем.
Именно этой теме и была посвящена серия коротких видео-роликов, снятых инструктором компании PENTESTIT Александром Дмитренко sinist3r, получивших название «Pivoting Everywhere».
SSH как наиболее распространенный инструмент системных администраторов
Рассмотрим один из часто используемых системными администраторами инструментов — SSH, позволяющий осуществлять как ставшие традиционными локальные и удаленные пробросы портов, так и использовать малоизвестную, но вместе с тем полезную особенность, которая позволяет экономить время и создавать новые пробросы портов в уже имеющейся ssh-сессии. Все подробности и наглядную демонстрацию работы вы найдете промо-видео.
Netcat — нестареющая классика
Второй эпизод серии нацелен на нестареющую классику — netcat. В нем вы найдете и создание netcat релеев, и работу с именованными каналами, и совместное использование netcat-релея с фреймворком Metasploit.
Windows. Relay and proxy
Третья серия раскрывает стандартные возможности Windows платформы по созданию релеев или прокси. В ней можно будет убедиться в том, что даже без каких-либо сторонних или доустановленных приложений вполне возможно создавать пробросы соединений до внутренних и недоступных напрямую хостов. При этом активно используются возможности штатного механизма netsh.
PowerShell
Финальная четвертая серия завершает материал рассмотрением специального модуля для PowerShell — крайне актуальная тема для пентестеров, поэтому обойти его стороной было просто невозможно. Используя его возможности атакующий получает доступ к бесчисленным низкоуровневым функциям Windows системы. Всё внимание было уделено модулю powercat, который, как следует из названия, представляет из себя реализацию классического netcat для PowerShell.
Результатом проведения этих действий становится возможность проводить атаки на внутренние хосты инфраструктуры, которые были бы невозможны из-за пределов сети, обходить политики NAT и FireWall, используя атакованную систему в качестве средства маршрутизации.
shanker
За ликбез статье зачёт. А вот практическая составляющая… Посмотрел бы я как на практике используете описанные методы
Это всё так… но у вас теория в отрыве от практики. На практике встречается куча подводных камней.
1. использование nmap через прокси, созданный как динамический проброс портов SSH-сервера скомпрометированной системы. Во-первых, нужно честно признаться, что в таком случае сканирование через nmap будет работать по-особенному. Вряд ли он найдёт UDP порты. К тому же, велика вероятность, что у него будут ложные срабатывания с TCP-портами: некоторые открытые он не увидит, а некоторые закрытые — гордо сообщит, что они есть. Далеко не каждый SSH-сервер позволяет себя использовать как прокси. Возьмите стандартный SSH-сервер Cisco.
Т.е. итоговое покрытие исследованной сети таким способом вызывает много вопросов. Раз уж занялись SSH — неясно почему не рассматривали вариант, когда SSH используется как построение VPN-туннеля. Да, там тоже куча нюансов, но в этом варианте можно будет использовать nmap полноценно и более доверять его результатам работы, а не гадать стоит ли верить ему. К тому же, можно будет использовать nmap для сканирования UDP-портов.
2. Диагностирование проблем при использовании прокси довольно осложнено. Пример: атакуемая удалённая система перезагружается, в связи с чем удалённый порт недоступен пару минут. Атакуя через прокси вы можете этого попросту не заметить. В итоге атака будет неудачная.
3. Netcat — полезная штука, но очень капризная в плане стабильности. Есть несколько версий этой утилиты, каждая со своим набором команд и капризностей. Есть похожие проблемы как с прокси: атакуемая система перезагружается и этого не заметить. Т.к. коннект на порт netcat проходит, а вот что дальше — дошёл ли пакет от netcat на атакуемый удалённый порт — неизвестно.
4. Что уж тогда не рассмотрели проброс порта через iptables? Намного стабильнее, чем использование netcat
5. А если уж копать туда дальше, то iptables+OpenVPN = нормальный доступ в удалённую сеть. Правда, только для устройств, где есть возможность запустить iptables и OpenVPN.
sinist3r
Вначале стоит отметить, что в материалах по ssh и netcat рассматриваются общие случаи часто используемых способов в условиях ограниченных прав и возможностей.
Безусловно на практике могут возникать различные проблемы и все варианты предусмотреть невозможно.
То что работа через прокси или релей накладывает свои ограничения это очевидно, но ведь речь идет не о том, что можно получить идеальный вариант.
Речь идет о том, что можно получить доступ или доставить транспорт до недоступной ранее сети или хоста.
Что касается iptables, конечно с его помощью можно тоже пробрасывать порты.
Но ведь netcat позволяет создавать релеи обладая минимальными правами в системе.
Именованный канал можно создавать в любом доступном для записи каталоге, например /tmp.
Для работы с iptables нужны существенно большие привилегии, а для openvpn может даже потребоваться так же и установка соответствующего пакета.
Кроме того, нельзя забывать, что когда речь идет о пентесте, зачастую запрещено устанавливать дополнительное ПО, а тот же netcat очень часто уже присутствует на linux хостах.
Относительно nmap, то UDP по большому счету требует всегда отдельного внимания, и без проксирования бывают ложные срабатывания и работает значительно дольше, но это уже нюансы связанные, как с этим транспортным протоколом, так и с сервисами, которые его используют.
Сканирование сервисов, опирающихся на TCP в большинстве случаев работает корректно.
Естественно, при этом часть режимов nmap будет недоступны, но базовый функционал работает.
Подытоживая сказанное — ограничения при работе через прокси (независимо от реализации) возможны и часто неизбежны, но в определенных ситуациях — это действительно работающий выход, и возможность развить атаку далее.
shanker
Ну тогда нужно подчёркивать минусы при рассмотрении всех вариантов. А то мои варианты раскритиковали. А что же со своими? Например, netcat очень любит «отваливаться» при нескольких подключениях\отключениях на порт. И работа с ним может превратиться в большую муку.
sinist3r
В условиях ограниченного количества времени, небольшого пространства для маневра и других факторов, единичный проброс TCP порта с помощью netcat может сыграть значительную роль в процессе проведения теста на возможность проникновения.
Если же стоит задача по администрированию, то безусловно использование OpenVPN или IPsec гораздо эффективнее для создания надежных подключений.
shanker
С таким же успехом я могу сказать, что в условиях ограниченного количества времени, небольшого пространства для маневра и других факторов, знание связки admin\admin при подключении к ресурсу может сыграть значительную роль в процессе проведения теста на возможность проникновения.
Это всё теория… Вы не говорите про ограничения, связанные с netcat. Почему? Потому что они редко встречаются или Вы сами не знаете область применения того, о чём пишите?
Насчёт редкости таких проблем.
Пробовали использовать этот метод, если удалённый сервер уязвим к heartbleed-уязвимости? Я, конечно, не мастер по netcat. Но вот с чем я столкнулся.
1. Проверяем, что сервер уязвим с помощью эксплоита. Эксплоит отрабатывает корректно:
2. Создаём перенаправление на уязвимый сервер (192.168.100.10) через netcat. У меня версия OpenBSD netcat (Debian patchlevel 1.105-7ubuntu1):
В логах netcat вроде бы всё корректно:
Натравливаем эксплоит и… облом:
sinist3r
Целью этого материала был показ технологий и приёмов, все примеры которые были показаны работают.
Рассматривать ограничения задачи не было.
Да и они будут обнаружены при первой же попытке использования, а в случае https еще и предсказуемы.
Кстати, с проблемой c SMTP раньше не встречался, после ваших слов еще раз проверил.
Обычный netcat имеющийся по дефолту в Debian линуксе.
Никаких доп условий.
Всё работает и телнет подключение и брутфорс логинов по SMTP через netcat релей.
Возможно тут и правда дело в карме :-)
shanker
Можете сообщить какая у Вас версия netcat? Буду собирать статистику работоспособности и глючности зоопарка версий netcat :)
sinist3r
Пакет
netcat-traditional
Version: 1.10-41