Comments 8
За ликбез статье зачёт. А вот практическая составляющая… Посмотрел бы я как на практике используете описанные методы
Это всё так… но у вас теория в отрыве от практики. На практике встречается куча подводных камней.
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.
Это всё так… но у вас теория в отрыве от практики. На практике встречается куча подводных камней.
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.
Вначале стоит отметить, что в материалах по ssh и netcat рассматриваются общие случаи часто используемых способов в условиях ограниченных прав и возможностей.
Безусловно на практике могут возникать различные проблемы и все варианты предусмотреть невозможно.
То что работа через прокси или релей накладывает свои ограничения это очевидно, но ведь речь идет не о том, что можно получить идеальный вариант.
Речь идет о том, что можно получить доступ или доставить транспорт до недоступной ранее сети или хоста.
Что касается iptables, конечно с его помощью можно тоже пробрасывать порты.
Но ведь netcat позволяет создавать релеи обладая минимальными правами в системе.
Именованный канал можно создавать в любом доступном для записи каталоге, например /tmp.
Для работы с iptables нужны существенно большие привилегии, а для openvpn может даже потребоваться так же и установка соответствующего пакета.
Кроме того, нельзя забывать, что когда речь идет о пентесте, зачастую запрещено устанавливать дополнительное ПО, а тот же netcat очень часто уже присутствует на linux хостах.
Относительно nmap, то UDP по большому счету требует всегда отдельного внимания, и без проксирования бывают ложные срабатывания и работает значительно дольше, но это уже нюансы связанные, как с этим транспортным протоколом, так и с сервисами, которые его используют.
Сканирование сервисов, опирающихся на TCP в большинстве случаев работает корректно.
Естественно, при этом часть режимов nmap будет недоступны, но базовый функционал работает.
Подытоживая сказанное — ограничения при работе через прокси (независимо от реализации) возможны и часто неизбежны, но в определенных ситуациях — это действительно работающий выход, и возможность развить атаку далее.
Безусловно на практике могут возникать различные проблемы и все варианты предусмотреть невозможно.
То что работа через прокси или релей накладывает свои ограничения это очевидно, но ведь речь идет не о том, что можно получить идеальный вариант.
Речь идет о том, что можно получить доступ или доставить транспорт до недоступной ранее сети или хоста.
Что касается iptables, конечно с его помощью можно тоже пробрасывать порты.
Но ведь netcat позволяет создавать релеи обладая минимальными правами в системе.
Именованный канал можно создавать в любом доступном для записи каталоге, например /tmp.
Для работы с iptables нужны существенно большие привилегии, а для openvpn может даже потребоваться так же и установка соответствующего пакета.
Кроме того, нельзя забывать, что когда речь идет о пентесте, зачастую запрещено устанавливать дополнительное ПО, а тот же netcat очень часто уже присутствует на linux хостах.
Относительно nmap, то UDP по большому счету требует всегда отдельного внимания, и без проксирования бывают ложные срабатывания и работает значительно дольше, но это уже нюансы связанные, как с этим транспортным протоколом, так и с сервисами, которые его используют.
Сканирование сервисов, опирающихся на TCP в большинстве случаев работает корректно.
Естественно, при этом часть режимов nmap будет недоступны, но базовый функционал работает.
Подытоживая сказанное — ограничения при работе через прокси (независимо от реализации) возможны и часто неизбежны, но в определенных ситуациях — это действительно работающий выход, и возможность развить атаку далее.
Ну тогда нужно подчёркивать минусы при рассмотрении всех вариантов. А то мои варианты раскритиковали. А что же со своими? Например, netcat очень любит «отваливаться» при нескольких подключениях\отключениях на порт. И работа с ним может превратиться в большую муку.
В условиях ограниченного количества времени, небольшого пространства для маневра и других факторов, единичный проброс TCP порта с помощью netcat может сыграть значительную роль в процессе проведения теста на возможность проникновения.
Если же стоит задача по администрированию, то безусловно использование OpenVPN или IPsec гораздо эффективнее для создания надежных подключений.
Если же стоит задача по администрированию, то безусловно использование OpenVPN или IPsec гораздо эффективнее для создания надежных подключений.
С таким же успехом я могу сказать, что в условиях ограниченного количества времени, небольшого пространства для маневра и других факторов, знание связки admin\admin при подключении к ресурсу может сыграть значительную роль в процессе проведения теста на возможность проникновения.
Это всё теория… Вы не говорите про ограничения, связанные с netcat. Почему? Потому что они редко встречаются или Вы сами не знаете область применения того, о чём пишите?
Насчёт редкости таких проблем.
Пробовали использовать этот метод, если удалённый сервер уязвим к heartbleed-уязвимости? Я, конечно, не мастер по netcat. Но вот с чем я столкнулся.
1. Проверяем, что сервер уязвим с помощью эксплоита. Эксплоит отрабатывает корректно:
2. Создаём перенаправление на уязвимый сервер (192.168.100.10) через netcat. У меня версия OpenBSD netcat (Debian patchlevel 1.105-7ubuntu1):
В логах netcat вроде бы всё корректно:
Натравливаем эксплоит и… облом:
Это всё теория… Вы не говорите про ограничения, связанные с netcat. Почему? Потому что они редко встречаются или Вы сами не знаете область применения того, о чём пишите?
Насчёт редкости таких проблем.
Пробовали использовать этот метод, если удалённый сервер уязвим к heartbleed-уязвимости? Я, конечно, не мастер по netcat. Но вот с чем я столкнулся.
1. Проверяем, что сервер уязвим с помощью эксплоита. Эксплоит отрабатывает корректно:
WARNING: server returned more data than it should — server is vulnerable!
2. Создаём перенаправление на уязвимый сервер (192.168.100.10) через netcat. У меня версия OpenBSD netcat (Debian patchlevel 1.105-7ubuntu1):
nc -v -k -n -l -p 8000 0<pipe | nc -v 192.168.100.10 443 1>pipe
В логах netcat вроде бы всё корректно:
Listening on [0.0.0.0] (family 0, port 8000)
Connection to 192.168.100.10 443 port [tcp/https] succeeded!
Connection from [192.168.30.2] port 8000 [tcp/*] accepted (family 2, sport 49172)
Натравливаем эксплоит и… облом:
Trying TLS 1.2…
Connecting…
Traceback (most recent call last):
File «s2.py», line 177, in main()
File «s2.py», line 122, in main
s.connect((args[0], opts.port))
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 111] Connection refused
Ну а если netcat использовать для подключения к HTTP c целью слегка побрутить параметры (3-4 запроса) — то он сваливается после закрытия первого подключения к нему, хотя ключ -k стоит.
Более того. Я не смог добиться нормального проброса HTTP и HTTPS. Страницы в браузере грузиться не будут. Даже с SMTP куча проблем:
telnet 192.168.30.2 8001
Trying 192.168.30.2…
Connected to 192.168.30.2.
Escape character is '^]'.
220 main.test.com ESMTP Exim 4.73 Fri, 29 Oct 2015 08:01:13 +0800
Connection closed by foreign host.
Т.е. закрывает соединение после коннекта.
При том, что напрямую к серверу — нормально:
telnet 192.168.100.10 25
Trying 192.168.100.10…
Connected to 192.168.100.10.
Escape character is '^]'.
220 main.test.com ESMTP Exim 4.73 Fri, 29 Oct 2015 08:17:16 +0800
Может, я такой вот невезучий и вечно попадаю в ситуации, когда мне хочется проклинать netcat при пентестах? Или у менягранаты не той системыверсия netcat не та? Или, может, Вы его не сильно использовали в реальной жизни?
Целью этого материала был показ технологий и приёмов, все примеры которые были показаны работают.
Рассматривать ограничения задачи не было.
Да и они будут обнаружены при первой же попытке использования, а в случае https еще и предсказуемы.
Кстати, с проблемой c SMTP раньше не встречался, после ваших слов еще раз проверил.
Обычный netcat имеющийся по дефолту в Debian линуксе.
Никаких доп условий.
Всё работает и телнет подключение и брутфорс логинов по SMTP через netcat релей.
Возможно тут и правда дело в карме :-)
Рассматривать ограничения задачи не было.
Да и они будут обнаружены при первой же попытке использования, а в случае https еще и предсказуемы.
Кстати, с проблемой c SMTP раньше не встречался, после ваших слов еще раз проверил.
Обычный netcat имеющийся по дефолту в Debian линуксе.
Никаких доп условий.
Всё работает и телнет подключение и брутфорс логинов по SMTP через netcat релей.
Возможно тут и правда дело в карме :-)
Sign up to leave a comment.
Pivoting Everywhere — техники продвижения внутрь локальной сети