Fsecurity | HH
Відкрити в Telegram
👾 Канал про КБ и пентест Наш Discord: https://discord.gg/Eg8aDS7Hn7 ✉️ По сотрудничеству: @OxHaskar 🍩 Поддержать: https://www.donationalerts.com/r/xackapb
Показати більше2 074
Підписники
Немає даних24 години
+67 днів
+1430 днів
Архів дописів
2 074
Repost from purple shift
Если вы занимаетесь пентестом беспроводных сетей, то наверняка встречали инфраструктуры на основе 802.11r (Fast BSS Transition) — это стандарт быстрого роуминга, который активно используется в корпоративных сетях, на производстве, в складских комплексах и т.д. Но вот незадача: ни HashCat, ни John the Ripper такие хэши не поддерживали.
Единственный рабочий вариант, который существовал до недавнего времени — использование однопоточного python-скрипта, который к тому же поддерживает только EAPOL и не умеет работать с PMKID. Это лучше, чем ничего, и такой вариант можно было использовать в качестве PoC и подбора по словарю из пары тысяч паролей. Но о каких-либо серьезных атаках по подбору пароля на GPU говорить не приходилось.
Причина в том, что криптографическая схема в случае 802.11r несколько отличается от классического WPA-PSK. Ключ PMK считается так же — через PBKDF2-HMAC-SHA1, но дальше начинается своя кухня: цепочка из трёх шагов на HMAC-SHA256, плюс финальный MIC через AES-128-CMAC. И всё это с дополнительными параметрами (MDID, R0KH-ID, R1KH-ID), специфичными для конкретной беспроводной сети.
Именно это пришлось реализовать нашим специалистам, когда они столкнулись с 802.11r на одном из проектов по анализу защищённости. И в итоге получился новый модуль для HashCat, с поддержкой обоих типов хэшей, PMKID и EAPOL для FT-PSK:
https://github.com/hashcat/hashcat/pull/4645
Так что если на очередном пентесте вам попадётся сеть с 802.11r — больше не нужно довольствоваться однопоточным скриптом. Скармливаем пойманные хэши в HashCat и едём дальше!
2 074
Repost from Cybred
Bluehammer
Парень с ником ChaoticEсlipse0 просто взял и дропнул на всех 0day с повышением привилегий через Defender. Он не объяснил своих действий, но vx-undeground со ссылкой на Xitter подтвердил, что эксплоит рабочий.
По словам исследователя, скоро будет еще один
Another 0day unpatched LPE will be released soon.
2 074
Repost from purple shift
Чтобы сделать вредоносные файлы невидимыми для систем защиты, атакующие используют различные техники. Самые известные — это руткиты и буткиты. Но иногда достаточно и более простых механизмов. Недавно мы наткнулись на технику маскировки процессов в Linux через
bind mount поверх /proc.
Когда утилита для монтирования файловых систем mount запускается с флагом bind, это позволяет "приклеить" одну директорию или файл в другую точку файловой системы. При этом исходные данные в целевой точке становятся невидимыми; фактически, они перекрываются содержимым примонтированного пути.
Атакующий с root-доступом может использовать это для маскировки процессов.
Например, процесс с PID 1234 можно спрятать через mount:
mount --bind /tmp/empty /proc/1234
После этого содержимое настоящего /proc/1234 перекрывается пустой директорией. Утилиты вроде ps, top или htop читают данные именно из /proc, поэтому для них процесс как будто исчезает. При этом сам процесс продолжает работать: слушает порты, выполняет код, держит соединения.
Иногда делают еще аккуратнее: поверх /proc/<pid>/exe или /proc/<pid>/cmdline монтируют другой файл. Тогда процесс вроде бы виден, но его бинарь или аргументы подменены.
Как ловить атаку?
Проверка mount-таблицы помогает обнаружить сокрытие процесса. Утилиты mount или findmnt покажут bind mounts внутри /proc. В нормальной системе их там почти не бывает.
С точки зрения правил обнаружения для SOC, отслеживаем запуски утилиты mount с соответствующими аргументами: "--bind", "-B", "-o bind" и "/proc")
Также имеет смысл мониторить системный вызов mount на уровне ядра. Например, для auditd простейшее правило аудита может выглядеть так:
auditctl -a always,exit -F arch=b64 -S mount -k mount_monitor
В файле /var/log/audit/audit.log будут фиксироваться события монтирования, включая bind mounts. При анализе стоит обращать внимание на операции, где точкой монтирования выступают пути внутри /proc.