## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-G0THAMRABB1T-CVE-2026-43284-DIRTYFRAG-DETECTION
# DirtyFrag CVE-2026-43284: проверка PoC и обнаружение с помощью auditd
**Область применения:** Проверка локального повышения привилегий (LPE) в Linux, ориентированная на путь XFRM/ESP, связанный с **CVE-2026-43284**.
Этот репозиторий содержит отчёт на английском языке и артефакты исследования, полученные в ходе контролируемой лабораторной проверки публичного PoC DirtyFrag. Основное внимание уделяется не руководству по эксплуатации, а документированию того, что было видно в журналах аудита Linux и как эти события можно преобразовать в практическую логику обнаружения для SOC.
Полный отчёт в формате PDF:
EN: `reports/DirtyFrag_CVE-2026-43284_EN.pdf`
PL: `reports/DirtyFrag_CVE-2026-43284_PL.pdf`
## Цель и область применения
Тест был выполнен для проверки, может ли обычный локальный пользователь получить root-оболочку на уязвимой лабораторной виртуальной машине, и для определения того, какие события можно зафиксировать с помощью auditd.
CVE-2026-43284 связана с неправильной обработкой общих фрагментов страниц при операциях ESP/IPsec. При определённых условиях локальный злоумышленник может повлиять на данные в кэше страниц и повысить привилегии. Ubuntu Security оценивает эту уязвимость как **CVSS 3.1: 7.8 High**.
Уязвимость| Область применения| Компонент| CVSS
---|---|---|---
CVE-2026-43284| XFRM/ESP Page-Cache Write| XFRM / ESP, esp4/esp6| 7.8 High
Технические ссылки:
* Публичный репозиторий PoC DirtyFrag: https://github.com/V4bel/dirtyfrag
* Ubuntu Security – CVE-2026-43284: https://ubuntu.com/security/CVE-2026-43284
* Блог Ubuntu – Исправления уязвимости Dirty Frag Linux: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available
## Тестовая среда
Полная базовая информация о системе: `evidence/logs/system-info-table.md`
## Результат
До выполнения PoC контекст теста представлял собой обычную учётную запись пользователя. После запуска `./exp` была получена root-оболочка, что подтверждено командами `whoami` и `id`.
## Сбор доказательств
После теста журналы auditd и сводные выходные данные были экспортированы в локальный каталог доказательств и скопированы в этот репозиторий.
## Структура репозитория
## Логика обнаружения auditd
Наиболее полезное обнаружение — это не единичное событие. Самый сильный сигнал — полная цепочка, наблюдаемая в коротком временном окне:
root@kitploit:~
user namespace -> vmsplice/splice -> ESP/XFRM -> su -> root shell with AUID of a normal user
### Соответствующие ключи auditd
### Восстановленная цепочка событий
## Пример корреляции SIEM
root@kitploit:~
IF
dirty_frag_unshare by auid>=1000
AND count(dirty_frag_vmsplice + dirty_frag_splice by same exe or pid) >= 3 within 600s
AND MAC_IPSEC_EVENT / XFRM activity within 1200s
AND (dirty_frag_su_exec OR execve with euid=0 and auid>=1000) within 1200s
THEN
alert = "Possible DirtyFrag CVE-2026-43284 Linux LPE"
severity = high/critical
## Рекомендации для SOC
* Примените исправление ядра и обеспечьте перезагрузку в исправленное ядро после обновлений.
* Собирайте телеметрию системных вызовов с помощью auditd, Falco, инструментов на основе eBPF или EDR.
* Не создавайте оповещения только на основе одного события `euid=0`; это также фиксирует легитимное использование `sudo`.
* Коррелируйте `unshare`, `vmsplice`, `splice`, активность XFRM/ESP, `su` и создание root-процессов из обычного сеанса пользователя.
* Рассмотрите возможность ограничения `kernel.unprivileged_userns_clone` там, где это допускает совместимость приложений.
* Проверьте, требуются ли модули ESP/IPsec на данном классе хостов, и при необходимости ограничьте загрузку ненужных модулей.
* Пересылайте журналы на удалённый сборщик или SIEM; после LPE локальные журналы могут быть изменены злоумышленником.
* Контролируйте качество auditd: `lost` должен оставаться `0` во время тестирования и производственного мониторинга.
* Поддерживайте плейбук по расследованию LPE в Linux, охватывающий изоляцию хоста, сбор журналов аудита, проверку работающего ядра и захват загруженных модулей.
## Примечания
Собранный статус auditd показал `lost=2555`, что означает, что некоторые события аудита могли быть потеряны. Ключевая цепочка по-прежнему видна, но в будущих тестах следует увеличить резерв аудита и подтвердить `lost=0` перед запуском PoC.
Отчёт намеренно сосредоточен на **CVE-2026-43284 / XFRM/ESP** , чтобы не смешивать область обнаружения SOC с другими путями, связанными с DirtyFrag.