Скрипты для kali linux

Инструменты Kali Linux

Список инструментов для тестирования на проникновение и их описание

hack-captive-portals

Описание hack-captive-portals

Скрипт для взлома любых перехватывающих порталов (Captive Portal), используя технику спуфинга MAC.

Метод спуфинга MAC является единственным универсальным методом для обхода беспроводных и некоторых проводных Перехватывающих Порталов, поскольку эксплуатируется основной принцип их работы, который заключается в том, что после того, как хост авторизовался в Captive portal, его MAC и IP адресу разрешён неограниченный доступ.

Всё, что нам нужно, это сниффить трафик сети, найти хост, который авторизовался и спуфить его IP и MAC адрес.

Спуфинг MAC зависит от вашей сетевой карты и драйвера, но сегодня большинство современных сетевых устройств поддерживают это.

Минусом метода является то, что, конечно же, в сети уже должен быть кто-то успешно прошедший аутентификацию, но в оживлённых аэропортах и лобби гостиниц это не такая уж трудная задача.

Автор: Stanislav Kotivetc

Справка по hack-captive-portals

У скрипта нет опций — достаточно его запустить и дождаться, когда он завершит свою работу.

Руководство по hack-captive-portals

Страница man отсутствует.

Примеры запуска hack-captive-portals

и ждите, когда он завершит свою работу.

Если появится строка

это означает, что вы можете пользоваться Интернет-доступом перехватывающего портала — каких-либо других настроек не требуется.

Установка hack-captive-portals

Установка в Kali Linux

Установка в BlackArch. Arch Linux и их производные

Установка в Debian, Linux Mint или Ubuntu

Информация об установке в другие операционные системы будет добавлена позже.

Источник

Найти и не обезвредить: пишем пентесты с Kali Linux

Kali и другие подобные инструменты помогают обнаружить уязвимости в вашем ПО. И лучше, если первыми их найдёте вы, а не злоумышленники.

Шило в мешке не утаить: по неведению (правда, в некоторых случаях — умышленно) даже крупные корпорации оставляют дыры в своей системе безопасности. Жизненно важно как можно быстрее (1) локализовать их и (2) пофиксить. К счастью, существует множество различных продуктов, которые помогают с первым пунктом. Среди них можно выделить Kali, дистрибутив Linux, разработанный для тестирования систем безопасности. В этой статье я расскажу, как использовать Kali Linux для исследования вашей системы и поиска слабых мест, имитируя атаку злоумышленника.

Дистрибутив Kali включает множество инструментов, каждый из которых имеет открытый исходный код. Достаточно запустить установку дистрибутива и все эти инструменты будут доступны из коробки.

В качестве подопытных я буду использовать две системы:

kali.usersys.redhat.com: 30 Гб памяти и 6 виртуальных CPU. Эта система будет выполнять сканирование «жертвы» и запускать атаки.

vulnerable.usersys.redhat.com: система с Red Hat Enterprise Linux 8 на борту. Вот её нужно будет атаковать.

Я не зря упомянул здесь технические характеристики оборудования. Некоторые из наших задач довольно требовательны к железу, особенно — к CPU системы 2, на которой будет работать сканер безопасности WordPress (WPScan).

Поиск открытых портов

Я начал с базового сканирования системы 2. Сканируя систему с помощью Nmap, можно узнать, какие порты и службы видны из системы 1, запускающей сканирование.

Итак, первым делом можно найти несколько «интересных» открытых портов — потенциальных слабых мест. На самом деле, любой открытый порт интересен, потому что с его помощью больше шансов взломать сеть. В этом примере 21, 22, 80 и 443 — это ещё и порты часто используемых служб. Но пока я просто занимаюсь разведкой и пытаюсь получить как можно больше информации о системе, которую хочу взломать.

После этого для более глубокого анализа я выбраю порт 80 и запускаю команду Nmap с аргументами -p 80 и -A. Это позволяет получить информацию об операционной системе и приложении, которое использует 80-й порт.

Здесь нас интересуют следующие строки:

Поиск информации о пользователях

Поскольку теперь я знаю, что это сервер WordPress, я могу использовать WPScan для получения информации о потенциальных уязвимостях. Хорошо бы найти несколько имён пользователей и их пароли. Чтобы найти их в данном в экземпляре WordPress, используем опции —enumerate u:

└─# wpscan —url vulnerable.usersys.redhat.com —enumerate u

__ _______ _____

\ \ /\ / /| |__) | (___ ___ __ _ _ __

\ \/ \/ / | ___/ \___ \ / __|/ _` | ‘_ \

WordPress Security Scanner by the WPScan Team

Sponsored by Automattic — https://automattic.com/

@_WPScan_, @ethicalhack3r, @erwan_lr, @firefart

[+] URL: http://vulnerable.usersys.redhat.com/ [10.19.47.242]

[+] Started: Tue Feb 16 21:38:49 2021

[i] User(s) Identified:

| Found By: Author Posts — Display Name (Passive Detection)

| Author Id Brute Forcing — Author Pattern (Aggressive Detection)

| Login Error Messages (Aggressive Detection)

| Found By: Author Posts — Display Name (Passive Detection)

| Author Id Brute Forcing — Author Pattern (Aggressive Detection)

| Login Error Messages (Aggressive Detection)

Отлично, найдены два пользователя: admin и pgervase. Я попытаюсь подобрать пароль для пользователя admin, используя словари паролей — текстовый файл с набором возможных вариантов. Я возьму словари из 3 231 и из 3 543 076 137 строк.

Подбор пароля с атакой по словарю

Для атаки по словарю можно использовать разные инструменты. Вот два примера команд с Nmap и WPScan:

Эти два инструмента, конечно же, могут гораздо больше, но и для подбора паролей тоже годятся.

А вот эта команда WPScan, например, выводит пароль в конце файла:

Раздел Valid Combinations Found в конце содержит имя пользователя admin и его пароль. На перебор 3 231 строк ушло всего две минуты.

У меня есть ещё один файл словаря с 3 238 659 984 уникальными записями, что займет гораздо больше времени.

Nmap выдаёт результат намного быстрее:

Правда, такое сканирование можно отследить по HTTPD-логам, которые будут обнаружены во взломанной системе:

Поиск Heartbleed-уязвимости

Чтобы получить информацию о HTTPS-сервере и SSL/TLS протоколах, я использую команду sslscan:

Мы видим, что в версиях протоколов, которые используются на сервере, Heartbleed-уязвимость не обнаружена:

Ну что ж, значит через модуль Heartbeat я не могу получить доступ к оперативной памяти и данным сервера. Что ж… видно не судьба 🙂

Советы по предотвращению и защите от взлома

Можно написать много статей про то, как противостоять атакам хакеров всех мастей. Тут я ограничусь общими рекомендациями:

Изучайте свою систему: какие порты открыты, какие порты должны быть открыты, кто должен иметь возможность видеть эти порты и какой объём трафика должен проходить через них. Nmap вам в помощь.

Используйте лучшие и передовые практики: то, что считается передовой практикой сегодня, перестанет быть таковой в ​​будущем. Важно быть в курсе новейших достижений в области информационной безопасности.

Грамотно настраивайте ваши продукты и их окружение: например, вместо того, чтобы позволять злоумышленнику постоянно атаковать вашу систему WordPress, заблокируйте его IP-адрес и ограничьте количество попыток входа в систему. Правда, блокировка IP-адреса часто оказывается бесполезной, потому что злоумышленники могут использовать разные адреса. Однако эту настройку легко включить, и она поможет отразить хотя бы некоторые атаки.

Создавайте и поддерживайте качественные резервные копии: если злоумышленник взломает одну или несколько ваших систем, возможность восстановить данные без танцев с бубном поможет сэкономить много времени и денег.

Проверяйте свои логи: как показывают приведённые выше примеры, команды сканирования и прочие проникающие манипуляции могут оставлять множество логов. Если вы заметили их вовремя, вы успеете защититься от взлома.

Обновляйте свою систему, приложения и любые дополнительные модули: специалисты Института стандартов и технологий США уверены, что «обновления обычно являются наиболее эффективным способом устранения уязвимостей и часто могут стать единственным по-настоящему эффективным решением».

Используйте дополнительные инструменты от поставщиков вашего ПО: например, в подписку Red Hat Enterprise Linux входит инструмент Red Hat Insights, который позволяет настроить вашу систему и своевременно предупреждает о потенциальных угрозах безопасности.

Полезные материалы (на английском языке)

То, что описано в этой статье, — лишь вершина айсберга. Чтобы погрузиться глубже, вы можете изучить следующие ресурсы:

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Источник

Хакерские секреты простых вещей

Содержание статьи

Обойти HTTPS с помощью proxy (Pretty Bad Proxy)

Решение

Хотелось бы начать сегодняшний Easy Hack с относительно старой атаки — возможности «обхода» HTTPS в браузере. Если точнее, возможности внедрить свой JavaScript-код в любой сайт, защищенный HTTPS, при условии, что злоумышленник может «вставить» свой прокси в настройках браузера жертвы. Да, эта атака не работает на современных топовых браузерах. Но, во-первых, еще шесть лет назад ей были подвержены все они, а во-вторых, она служит отличным примером основных проблем с HTTPS (SSL). Да и с технологической точки зрения интересна.

WARNING

Корпоративная сеть, все пользователи ходят через корпоративный прокси. Мы производим DNS- или ARP-спуфинг и подменяем официальный прокси на свой. Также есть автоматическое включение прокси с использованием технологии WPAD (Web Proxy Autodiscovery Protocol), которая по умолчанию активирована в Windows-системах («Автоматическое определение настроек» в IE).

Далее. Почему нам так важно именно стать прокси-сервером? Дело заключается в уникальности работы через них. Если при обычном подключении по SSL данные идут напрямую и, не считая первых SSL-пакетов, там все зашифровано, то c прокси добавляется еще один шаг, который не зашифрован.

Итак, по RFC, для работы по HTTPS через прокси был придуман дополнительный метод — CONNECT. Когда пользователь пытается подключиться по HTTPS к серверу, его браузер сначала посылает запрос плейн-текстом на прокси такого вида:

Подключение по HTTPS через proxy

Хакер #183. Малварь для Android

Прокси же пытается подключиться по указанному IP и порту и, если все хорошо, отвечает:

При этом он не обрывает подключение (TCP), а начинает просто пересылать весь трафик от пользователя на сервер. То есть отсюда и далее идет обычное подключение по SSL. Теория, я думаю, ясна. Перейдем к самой уязвимости, которая была в браузерах.

Проблема была в том, что браузер обрабатывал ответ прокси (например, ошибку при подключении) в контексте домена сайта, к которому он подключался. И что еще круче — JavaScript тоже работал! Прокси-серверу ничего не стоило вернуть браузеру ошибку со своим JS и из него получить те же куки, например.

Идея атаки на HTTPS с proxy

Хотелось бы подчеркнуть здесь, что фактически ничто не нарушало само HTTPS-соединение. Оно как было зашифровано и нетронуто, так и осталось. Проблема была уровнями выше — в same origin policy (SOP) браузера, по которому все было вполне корректно: вне зависимости от того, откуда пришли данные, если origin тот же, значит, и доступ есть. Причем разработчики разрешали вывод ошибок от proxy из хороших побуждений — чтобы у пользователя была возможность видеть кастомную информацию о причинах ошибки подключения.

Прокачать Kali Linux

Решение

Я думаю, ты в курсе, что Offensive Security значительно переосмыслили свой знаменитый пентестерско-хакерский дистрибутив BackTrack и конкретно его переделали. Как минимум, теперь он называется Kali, и в качестве основы взяли Debian (раньше был Ubuntu). Также ядро теперь первой свежести, а не какой-нибудь LTS. По моему мнению, проблем только добавилось, но, думаю, у них были веские аргументы для перемен. Но задача не об этом.

Как это ни странно, Kali создавался как дистрибутив, на котором было бы предустановлено и настроено все необходимое ПО для наших с тобой дел. Но и сторонних тулз оооочень много, и они систематически обновляются и меняются. Получается, когда мы скачиваем Kali, уверен, нам чего-то да не хватит из предустановленного арсенала. И возникает потребность в установке дополнительных приложений, причем из сырцов. Это может стать очень приличным геморроем, особенно если возникают конфликты различных версий библиотек, языков. А кроме того, все это надо еще и обновлять… Также есть целый ворох проблем в виде необходимости патчить разного рода VM Tools, чтобы они таки заработали под ядрышком 3.12.

Но наше же дело — ломать, а не ПО ставить. А потому рекомендую воспользоваться скриптами, которые помогут тебе автоматизировать вышеупомянутые задачи.

Во-первых, это небольшой скриптец-инсталлятор — Lazy-Kali. Он дает возможность накачать ряд прикольных тулз (Unicornscan, Smbexec, Flash, Nautilus, Xssf, Ettercap 0.7.6, PwnStar и другие), а также удобненький интерфейс для обновления всех основных систем/тулз.

Во-вторых, я хотел бы тебе презентовать набор скриптов для комфортной работы Kali Linux от коллеги по DSec’у — @090h (пользуясь положением, передаю ему слова: «Ты — крутан :)»).

Данный набор скриптов полезен при первичной установке Kali для инстала большого количества софта в автоматическом режиме, также имеется скрипт для быстрого тюнинга. Ну и для любителей покопаться со всякими железками на ARM/MIPS есть возможность быстрого разворачивания тулчейнов под нужную архитектуру.

Перечислять все не имеет смысла — по исходникам все понятно. В общем, очень рекомендую. Взять можно здесь.

Для тех, кому скриптов мало и хочется большего, есть хорошая связка Vagrant + Packer, которая позволяет запилить себе виртуалочку Kali в автоматическом режиме. Шаблоны для виртуалки лежат рядом.

Определить IP-адрес, используя WEBRTC

Решение

Не так давно в браузеры пришла технология WebRTC (Web Real-Time Communication). Суть ее заключается в том, чтобы дать браузерам встроенную универсальную возможность, то есть без плагинов, осуществлять звонки, видеоконференции, передачу данных. Логично, что она возложена на специальный API в JS. И понятное дело, что возможность эта сможет потеснить Skype, например.

Сейчас эта технология поддерживается уже всеми топовыми браузерами (IE c 10-й версии). И даже есть примеры интеграции и использования технологии (если интересно — посмотри на хабре).

С другой стороны, у этой технологии для наших целей также есть кое-что. А именно — возможность получить IP-адрес системы. Заходит к тебе кто-то на сайт, а ты можешь узнать его IP, только используя возможности JavaScript’а. Причем, что очень важно, не IP-адрес NAT’a (вай-фай роутера или другого девайса) или IP прокси, а именно конкретного хоста в его подсети. К тому же можно получить IP-адреса всех сетевых интерфейсов. Никаких warning’ов при этом не отображается. Все тихо и незаметно.

Если кратко, то причина этой новой возможности JS в том, что хотя WebRTC и является P2P-технологией, но для нахождения хостов, для подключений между друг другом используется дополнительный сервер. Так вот, для обмена данными для подключения также был придуман протокол — SDP (Session Description Protocol). Для подключения в SDP, наряду с другой информацией, передаются и IP-адреса. Надеюсь, что не ошибся :).

Так что мы фактически приходим к тому, что наши внутренние IP уже не являются приватной информацией. Можно только надеяться, что потом для доступа к этому API потребуется подтверждение от пользователя.

PoC можно найти здесь.

Получить DNS имени по IP или rDNS

Решение

Это еще одна задачка, относящаяся к сбору информации об атакуемой сети. В данном случае мы опять-таки используем возможности DNS. Казалось бы, что тут вообще можно получить? Имеем мы, например, имя сервера нашей жертвы, резолвим его и получаем IP-адрес. Далее резолвим обратно из IP-адреса — смотрим получившееся имя. Иногда оно может отличаться от того, что было. Вдобавок к этому можно провести обратный резолв (из IP в доменное имя) и для соседних серверов, чтобы расширить attack surface… С этими задачками может и nslookup/dig справиться. Идейно здесь должно все быть понятно. Но мне бы хотелось обратить твое внимание именно на механизмы, которые используются при этом. Эти тонкости помогут тебе для определения количества серверов — «соседей» по хостингу.

Итак, у нас есть имя домена жертвы и его IP-адрес. Что же происходит при обратном резолве IP-адреса (nslookup 55.66.55.33)? По твоему запросу твой DNS-сервер пытается найти PTR-запись для этого IP-адреса. При этом DNS-сервер, который ответит тебе на запрос, будет другой, а не тот, что вернет обычные записи (MX, A, TXT…). Звучит странновато, но если пронаблюдать последовательность, то становится понятно.

Во-первых, для резолва IP-адресов действует обычный подход (иерархия). Для того чтобы сделать их валидного вида, просто создана специальная зона «.in-addr.arpa» и обратная последовательность IP-адреса. Например, 223.19.109.62.in-addr.arpa для 62.109.19.223.

Полезность обратного резолва — нахождение других доменных имен

Далее, когда ты просишь свой DNS-сервер сделать обратный резолв, то он повторяет классический проход по иерархии. Сначала отправляет запрос на сервер один из рутовых DNS-серверов (a.root-servers.net, например). Тот отвечает именем сервера, ответственного за эту зону. Например, за 62.in-addr.arpa отвечает tinnie.arin.net. То есть мы увидим здесь один из основных регистраторов. Теперь мы делаем запрос уже к нему. Его ответ будет уже решающим.

Мы получим имя DNS-сервера, ответственного за диапазон IP-адресов. Это может быть провайдер или организация, то бишь автономная система (AS). Сам диапазон IP мы можем запросить через стандартную команду whois. У этого сервера мы можем напрямую запросить все PTR-записи по всему диапазону IP.

Таким образом, я думаю, теперь все встает на свои места. PTR-записи находятся на DNS-сервере, ответственном за диапазон IP, а не DNS доменной зоны. Резолв же идет стандартным путем по иерархии.

Обнаружили ns1.ispsystem.net, который отвечает за PTR-запись brrr.org.ru

Кстати, в продолжение прошлых тем про спуфинг email’ов, могу добавить, что некоторые почтовые серверы не желают получать почту с хостов без PTR-записи. Говорят, данный способ спасает от спама. Эта проблема решабельна — купить сервак с PTR-записью очень просто/дешево. Так что нас это не остановит, но знать о потенциальных проблемах желательно.

Собрать информацию с помощью dnsenum

Решение

Итак, задачка выше, наверное, была одной из последних про сбор инфы через DNS. В Easy Hack’е за последние несколько лет были описаны все основные методы по recon’у. Во всяком случае, других я пока что не знаю :).

Но с другой стороны, большая части информации была связана именно с методами, их причинами, и в качестве примеров приводились «точечные» инструменты — dig/nsloolup. Для понимания работы это то, что нужно. Но для пентестерских будней необходимы более быстрые и автоматизированные инструменты. Примером такой штуки служит dnsenum. Он входит в поставку Kali/BackTrack.

Списочек того, что он умеет делать:

• собирать A-, NS-, MX-записи;
• выполнять AXFR (трансфер зоны) для DNS-серверов;
• получать поддомены по гуглу;
• брутфорсить поддомены;
• производить реверс-запросы по диапазону из whois’а.

Не могу сказать, что эта тулза лучшая среди конкурентов (а аналогов много). Гуглохакинг, например, не очень, но все-таки она хороша, быстра и проста. Так что если еще не подобрал себе что-то — попробуй ее.

Спрятать JavaScript в GIF/BMP и обойти CSP

Решение

В последних версиях современных браузеров появилась такая интересная технология — CSP (content security policy). Недавно в «Хакере» была хорошая статья на эту тему, так что в подробности CSP я вдаваться не буду, а лишь напомню основные моменты.

Итак, задача, стоящая перед CSP, — это снизить последствия от XSS-уязвимостей (и не только их). Сервер в ответе добавляет HTTP-заголовок, в котором указывает, с каких доменов разрешена подгрузка JavaScript’ов, картинок, CSS-стилей. К тому же по умолчанию запрещается исполнение inline JS скриптов. Таким образом, даже если хакер может внедрить на страницу произвольный HTML, то яваскрипт payload нельзя будет подгрузить с хакерского ресурса. Мне это чем-то напоминает DEP как механизм защиты памяти: по сути, это ограничение того, какой код может исполняться, а какой — нет.

Хотя технология и подвергается критике. Мне кажется, что она приносит приличный ряд трудностей при эксплуатации XSS’ок, иногда совсем сводя возможность эксплуатации на нет. А как-никак XSS — самая распространенная уязвимость веб-приложений. Главное, не считать CSP «серебряной» пулей, которая решит все проблемы. CSP отлично себя может показать на небольших и «целостных» сайтах, требующих высокого уровня защищенности. Например, на сайтах интернет-банкинга.

Но наша цель — это обход CSP. Что же мы можем сделать? Если мы вспомним, что CSP указывает, откуда скрипты могут быть загружены и исполнены, то получается, туда нам и надо подгрузить наш скрипт. Как же это сделать?

Один из вариантов следующий. На многих сайтах сейчас есть возможность залить свои картинки, и если домен, куда попадают картинки, также входит в скоуп CSP, то мы получаем простой способ обхода CSP. Загружаем на атакуемый сайт свою картинку, которая в то же время является и валидным JavaScript-файлом, и в XSS ссылаемся на нее.

Теперь глубже. Как же это возможно? Здесь есть несколько основополагающих факторов. Во-первых, вспомним, что когда мы подгружаем JS через script src=, то браузер игнорирует тип получаемого файла, то есть заголовок «Content-Type: image/gif», который отдается сервером при загрузке gif-картинки. Фактически это может быть любой файл. Во-вторых, браузер будет его парсить как JS. Получается, главное — чтобы файл был валидным JS-ником. Таким образом, делаем вывод, что мы можем обойти CSP при подгрузке любого типа файла (почти), если внутри спрятать валидный JS.

Но достаточно часто на сервере тип файла проверяется при загрузке. А потому встает задача и обойти фильтр, то есть получить одновременно и валидный JS, и валидную картинку при этом.

На самом деле это не очень трудно (в конце топика ты легко сможешь сделать это сам). Но вот Saumil Shah на конференции добился еще большего. Для GIF и BMP он смог и сделать валидный JS-файл, и сохранить возможность визуализации картинки. Техника называется imajs.

Если мы подключаем такую картинку через — она отображается, если через

Check Also

Obsidium fatality. Обходим триальную защиту популярного протектора

Продолжаем разговор о популярных защитах программ и способах их обхода. На очереди Obsidiu…

Источник