Идея этого материала состоит в том, чтобы наглядно показать к чему могут привести дефолтные настройки или внесения опасных изменений в конфигурацию, независимо от вендора.
К сожалению, в случае установки Firebird на Windows пароль меняют крайне редко.
Неоднократно сталкивался с masterkey.
В свою очередь подключение внешних UDF функций — не редкость, иногда их тоже включают для своих нужд.
Поэтому рассмотренный сценарий вполне реалистичен для Windows платформы.
Если используется Linux, то безусловно там ситуация с дефолтными настройками намного лучше.
Имеются ввиду атаки направленные на потенциальные уязвимости связанные с дефолтными настройками, а так же часто встречающиеся ошибки в процессе администрирования.
Целью этого материала был показ технологий и приёмов, все примеры которые были показаны работают.
Рассматривать ограничения задачи не было.
Да и они будут обнаружены при первой же попытке использования, а в случае https еще и предсказуемы.
Кстати, с проблемой c SMTP раньше не встречался, после ваших слов еще раз проверил.
Обычный netcat имеющийся по дефолту в Debian линуксе.
Никаких доп условий.
Всё работает и телнет подключение и брутфорс логинов по SMTP через netcat релей.
Возможно тут и правда дело в карме :-)
В условиях ограниченного количества времени, небольшого пространства для маневра и других факторов, единичный проброс TCP порта с помощью netcat может сыграть значительную роль в процессе проведения теста на возможность проникновения.
Если же стоит задача по администрированию, то безусловно использование OpenVPN или IPsec гораздо эффективнее для создания надежных подключений.
Вначале стоит отметить, что в материалах по ssh и netcat рассматриваются общие случаи часто используемых способов в условиях ограниченных прав и возможностей.
Безусловно на практике могут возникать различные проблемы и все варианты предусмотреть невозможно.
То что работа через прокси или релей накладывает свои ограничения это очевидно, но ведь речь идет не о том, что можно получить идеальный вариант.
Речь идет о том, что можно получить доступ или доставить транспорт до недоступной ранее сети или хоста.
Что касается iptables, конечно с его помощью можно тоже пробрасывать порты.
Но ведь netcat позволяет создавать релеи обладая минимальными правами в системе.
Именованный канал можно создавать в любом доступном для записи каталоге, например /tmp.
Для работы с iptables нужны существенно большие привилегии, а для openvpn может даже потребоваться так же и установка соответствующего пакета.
Кроме того, нельзя забывать, что когда речь идет о пентесте, зачастую запрещено устанавливать дополнительное ПО, а тот же netcat очень часто уже присутствует на linux хостах.
Относительно nmap, то UDP по большому счету требует всегда отдельного внимания, и без проксирования бывают ложные срабатывания и работает значительно дольше, но это уже нюансы связанные, как с этим транспортным протоколом, так и с сервисами, которые его используют.
Сканирование сервисов, опирающихся на TCP в большинстве случаев работает корректно.
Естественно, при этом часть режимов nmap будет недоступны, но базовый функционал работает.
Подытоживая сказанное — ограничения при работе через прокси (независимо от реализации) возможны и часто неизбежны, но в определенных ситуациях — это действительно работающий выход, и возможность развить атаку далее.
Это проект того самого девелопера, который в своё время создал веб фронтенд для IOU.
Теперь разработка iou-web завершена, и разрабатывается только UNetLab.
Просто пока это ранняя бета версия.
В первую очередь было необходимо связывать IOU с различными виртуальными машинами.
Проверил через Ethernet Switch, тоже вылетает сообщение об ошибке.
Возможно, в следующих версиях как-то поправят такую ситуацию.
Напомню, что протокол появился в 1995м году, когда железок умеющих делать аппаратную проверку чексум и всего прочего еще не было в природе.
Поэтому задача увеличения скорости все же стояла у разработчиков.
разработчики думали и о безопасности протокола
О безопасности тогда не думали, в те времена всё было плейн текстом.
Именно по этому перекочевало множество старых и появились новые уязвимости в IPv6.
IPsec не является каким-либо обязательным к использованию элементом в IPv6.
Основной посыл, который я пробовал передать в этой статье, это то, что IPv6 уже пришел, его уже нужно знать и в том числе быть готовым к новым угрозам, которые он в себе несет.
Согласен с тем, что определенные трудности IPv6 с собой приносит.
Но ситуация состоит в том, что переход на него неизбежен и этот переход уже идет полным ходом.
Если брать обычного клиента, то в случае нативного получения IPv6 от оператора проблем обычно не возникает.
Всё происходит прозрачно, так же как в IPv4, прилетит вся нужная информация и в большинстве случаев всё будет жужжать.
Если коснуться ситуации с различными IPv6 туннелями, то по статистике мирового IPv6 трафика они уже своё отжили, доля ничтожная, преобладает уже чистый IPv6.
На самом деле, поработав месяц — два со средней IPv6 сетью, уже начинаешь ориентироваться по адресам и они не вызывают такого отторжения, как в начале.
И разобраться получается без особых проблем.
Но протокол конечно же многократно допиливался и по прежнему далек от идеального.
Это было сделано для того чтобы исключить возможность дубликатов таких адресов.
Затем уже стали добавлять различные секьюрити фичи, и количество таких адресов на интерфейсе стало расти.
Scapy использует в работе PF_PACKET/SOCK RAW, и операционка даже не догадывается о том, что должны приходить какие-то пакеты.
Поэтому и приходится делать некоторые ухищрения.
И далее, вызывая переменную syn_ack увидеть ответ, но как вы понимаете, если соединение еще не установилось, то особо там данных вы не найдете.
В статье описано как вручную установить трехэтапное соединение (рукопожатие), после которого уже можно будет отправлять и получать данные.
Неоднократно сталкивался с masterkey.
В свою очередь подключение внешних UDF функций — не редкость, иногда их тоже включают для своих нужд.
Поэтому рассмотренный сценарий вполне реалистичен для Windows платформы.
Если используется Linux, то безусловно там ситуация с дефолтными настройками намного лучше.
netcat-traditional
Version: 1.10-41
Рассматривать ограничения задачи не было.
Да и они будут обнаружены при первой же попытке использования, а в случае https еще и предсказуемы.
Кстати, с проблемой c SMTP раньше не встречался, после ваших слов еще раз проверил.
Обычный netcat имеющийся по дефолту в Debian линуксе.
Никаких доп условий.
Всё работает и телнет подключение и брутфорс логинов по SMTP через netcat релей.
Возможно тут и правда дело в карме :-)
Если же стоит задача по администрированию, то безусловно использование OpenVPN или IPsec гораздо эффективнее для создания надежных подключений.
Безусловно на практике могут возникать различные проблемы и все варианты предусмотреть невозможно.
То что работа через прокси или релей накладывает свои ограничения это очевидно, но ведь речь идет не о том, что можно получить идеальный вариант.
Речь идет о том, что можно получить доступ или доставить транспорт до недоступной ранее сети или хоста.
Что касается iptables, конечно с его помощью можно тоже пробрасывать порты.
Но ведь netcat позволяет создавать релеи обладая минимальными правами в системе.
Именованный канал можно создавать в любом доступном для записи каталоге, например /tmp.
Для работы с iptables нужны существенно большие привилегии, а для openvpn может даже потребоваться так же и установка соответствующего пакета.
Кроме того, нельзя забывать, что когда речь идет о пентесте, зачастую запрещено устанавливать дополнительное ПО, а тот же netcat очень часто уже присутствует на linux хостах.
Относительно nmap, то UDP по большому счету требует всегда отдельного внимания, и без проксирования бывают ложные срабатывания и работает значительно дольше, но это уже нюансы связанные, как с этим транспортным протоколом, так и с сервисами, которые его используют.
Сканирование сервисов, опирающихся на TCP в большинстве случаев работает корректно.
Естественно, при этом часть режимов nmap будет недоступны, но базовый функционал работает.
Подытоживая сказанное — ограничения при работе через прокси (независимо от реализации) возможны и часто неизбежны, но в определенных ситуациях — это действительно работающий выход, и возможность развить атаку далее.
http://habrahabr.ru/company/xakep/blog/244383/
Теперь разработка iou-web завершена, и разрабатывается только UNetLab.
Просто пока это ранняя бета версия.
VIRL.topology.png
Проверил через Ethernet Switch, тоже вылетает сообщение об ошибке.
Возможно, в следующих версиях как-то поправят такую ситуацию.
Напомню, что протокол появился в 1995м году, когда железок умеющих делать аппаратную проверку чексум и всего прочего еще не было в природе.
Поэтому задача увеличения скорости все же стояла у разработчиков.
О безопасности тогда не думали, в те времена всё было плейн текстом.
Именно по этому перекочевало множество старых и появились новые уязвимости в IPv6.
IPsec не является каким-либо обязательным к использованию элементом в IPv6.
Основной посыл, который я пробовал передать в этой статье, это то, что IPv6 уже пришел, его уже нужно знать и в том числе быть готовым к новым угрозам, которые он в себе несет.
Но ситуация состоит в том, что переход на него неизбежен и этот переход уже идет полным ходом.
Если брать обычного клиента, то в случае нативного получения IPv6 от оператора проблем обычно не возникает.
Всё происходит прозрачно, так же как в IPv4, прилетит вся нужная информация и в большинстве случаев всё будет жужжать.
Если коснуться ситуации с различными IPv6 туннелями, то по статистике мирового IPv6 трафика они уже своё отжили, доля ничтожная, преобладает уже чистый IPv6.
И разобраться получается без особых проблем.
Но протокол конечно же многократно допиливался и по прежнему далек от идеального.
Затем уже стали добавлять различные секьюрити фичи, и количество таких адресов на интерфейсе стало расти.
Поэтому и приходится делать некоторые ухищрения.
И далее, вызывая переменную syn_ack увидеть ответ, но как вы понимаете, если соединение еще не установилось, то особо там данных вы не найдете.
В статье описано как вручную установить трехэтапное соединение (рукопожатие), после которого уже можно будет отправлять и получать данные.
А так, да, вы правы.