Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
CVE-2022-37706 — PoC | Kitploit
Инструменты/GitHubGitHub/sanan2004/cve-2022-37706
Повышение привилегийАнализ уязвимостейЭксплуатацияОбратная инженерияCTFТестирование на ПроникновениеКомандование и УправлениеОбучение и ОбразованиеЭксплуатация Бинарных Файлов
GitHubsanan2004/cve-2022-37706

CVE-2022-37706

PoC

42 лет назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться
Репозиторий

CVE-2022-37706

CVE-2022-37706-poc-zoom

Привет, ребята, на этот раз я расскажу о недавнем 0-day, который я нашёл в одном из
главных оконных менеджеров Linux под названием Enlightenment (https://www.enlightenment.org/).
Этот 0-day позволяет любому пользователю получить root-права очень легко и мгновенно.
Эксплойт протестирован на Ubuntu 22.04, но должен работать и на любом другом дистрибутиве.

Прежде всего, Enlightenment — это оконный менеджер, композитор и минимальное рабочее окружение
для Linux (основной платформы), BSD и любых других совместимых UNIX-систем.

Я установил этот оконный менеджер, чтобы немного поэкспериментировать с ним. Мне было интересно,
так как он содержит много инструментов и, честно говоря, выглядит довольно аккуратно.

После установки пакета с помощью apt install enlightenment я изучил установленные файлы и каталоги
в своей системе: множество модулей и множество вспомогательных бинарников, но самое интересное — это :

root@kitploit:~
➜  enlightenment cd /usr/lib/x86_64-linux-gnu/enlightenment/
➜  enlightenment find . -perm -4000                         
./utils/enlightenment_ckpasswd
./utils/enlightenment_system
./utils/enlightenment_sys

Он устанавливает некоторые SUID-бинарники, и тогда я подумал, смогу ли я использовать один из них
для повышения привилегий до root. Все бинарники выглядели безопасными и хорошо написанными.
Бинарник, о котором мы будем говорить, — это enlightenment_sys.

Как и для любой другой цели, мы выбираем стратегию после предварительной оценки;
смотрите мой блог, если ещё не читали (https://pwn-maher.blogspot.com/2020/10/vulnerability-assessment.html)

Я аудировал код по нисходящему подходу.
А поскольку этот оконный менеджер с открытым исходным кодом, исходный код будет доступен
для всех этих бинарников и модулей.
Итак, первое, что я сделал, — выполнил apt source enlightenment, чтобы получить весь исходный код,
и, немного покопавшись, мы можем добраться до кода целевого бинарника.

Но для отладки бинарника я загрузил его в Ghidra для анализа и получения адресов
для установки точек останова и всего такого.
С первого раза символы не были найдены, но они и не понадобились, так как бинарник
оказался относительно небольшим.
Удивительно, но мне было гораздо приятнее смотреть на декомпилированный псевдокод
Ghidra, чем напрямую на исходники (избегая макросов и проверок на используемую ОС
для компиляции конкретного блока кода).

Итак, приступим к анализу.

1- Поиграем с бинарником.
Давайте запустим файл, чтобы увидеть некоторую информацию о нашей цели:
Screenshot

Запуск бинарника не даёт никакого вывода:
Screenshot

Передача аргумента --help выдала такой вывод:
Screenshot
Извините, я буду использовать это для получения root.

Далее просто выполним strace и посмотрим, не использует ли он какие-либо подозрительные системные вызовы, такие как execve или openat:
strace ./enlightenment_sys 2>&1 | grep open
Screenshot
Он просто открывает известные библиотеки в местах, где у нас нет права на вмешательство.

strace ./enlightenment_sys 2>&1 | grep exec
Screenshot

2- Давайте реверсим бинарник и затем эксплуатируем его.

Я создал новый проект в Ghidra и загрузил этот конкретный бинарник.
Поскольку символы не были найдены, мы можем найти функцию main, используя entry.
Первый аргумент функции entry — это сама main.
Я переименовал её в main для дальнейших ссылок.
Прокрутив немного вниз, я уже вижу, что используется функция system().

Как пвнер, я трачу дни на задачи, чтобы вызвать эту конкретную функцию x)
Я реверсил бинарник в поисках ошибки повреждения памяти или проблем с кучей,
но на самом деле это была странная инъекция команд.
Бинарник принимает все меры безопасности перед запуском system, но, к сожалению,
мы всегда можем внедрить туда наши данные.
Screenshot

Хорошо, теперь давайте пройдёмся по бинарнику сверху до нашей функции system, пытаясь
внедрить туда наши данные.

Сначала бинарник просто проверяет, является ли первый аргумент --help или -h, и показывает
то сообщение, которое мы видели ранее.
Screenshot

Во-вторых, он повышает свои привилегии до root.
Screenshot

Затем он удаляет почти все переменные окружения (меры безопасности), чтобы не вызвать
другой непредусмотренный бинарник.
Screenshot

Итак, если первый аргумент, который мы ввели, — это 'mount', он войдёт в эту ветку,
проверит некоторые переданные флаги; эти флаги будут установлены в стеке.

Затем он проверяет, является ли следующий параметр после mount 'UUID=', — мы не хотим
попадать сюда, поэтому мы передали '/dev/../tmp/;/tmp/exploit'.
Screenshot
Таким образом мы проходим проверку в строке 410, проверку strncmp.
Потому что если оно не начинается с /dev/, бинарник завершится.
Далее следует вызов stat64 для этого файла, который мы предоставили. Обратите внимание,
что мы можем создать папку с именем ';', что и приведёт к инъекции команды.
Пока что эксплойт уже создал этот файл /dev/../tmp/;/tmp/exploit,
но это не тот эксплойт, который будет вызван.
Screenshot
Screenshot

Теперь мы приближаемся к system().
Теперь p (указатель) обновляется до последнего аргумента, переданного нашему SUID-бинарнику,
/tmp///net.

Зачем указывать /tmp///net, если можно передать /tmp/net?
Мы обойдём эту проверку:
if (((next_next == (char *)0x0) || (next_next[1] == '\0')) || ((long)next_next - (long)p != 6))
Нам нужно, чтобы /tmp/net существовал и /tmp/// имел длину 6.

Теперь последний stat64 проверит существование '/dev/net'
__snprintf_chk(cmd,0x1000,1,0x1000,"/dev%s",next_next);
И найдёт его, так что мы проходим эту последнюю проверку.

Теперь он проверит доступность некоторых файлов, но это неважно на данный момент,
потому что мы готовы и близки к запуску произвольного выполнения команд.

Теперь eina_strbuf_new() просто инициализирует команду, которая будет передана в system.
Проблема в том, что мы ввели её как:

/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), "/dev/../tmp/;/tmp/exploit" /tmp///net

Но бинарник несколько раз вызывает eina_strbuf_append_printf(), и становится
/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), /dev/../tmp/;/tmp/exploit /tmp///net
Обратите внимание, что двойные кавычки удалены, и мы сможем вызвать /tmp/exploit
от имени root.
Screenshot

Бинарник старался изо всех сил предотвратить любое нежелательное поведение, но, как обычно,
всё можно взломать. Я не ожидал, что смогу использовать логическую ошибку такого рода.
Хочу, чтобы следующее CVE было повреждением памяти, приводящим к локальному повышению привилегий до root.

Скачать инструмент