Уязвимость

Компания FortiGate выпустила обновление версии в феврале, исправляющее несколько уязвимостей среднего и высокого уровня риска. Одна из критических уязвимостей — это неавторизованная уязвимость выхода за границы записи в SSL VPN. В предупреждении об уязвимости указано, что эта уязвимость может эксплуатироваться в реальных атаках. В этой статье будет представлен анализ автора по процессу эксплуатации этой уязвимости для достижения удаленного выполнения кода.

Среда, используемая для анализа уязвимости в этой статье — FGT_VM64-v7.4.2.F-build2571

diff

Сравнивая бинарные файлы исправленных версий (7.4.2 и 7.4.3), анализ показал, что исправляющий код находится в функции sub_18F4980(7.4.2).

Анализируя эту функцию, нетрудно заметить, что ее логика заключается в чтении тела запроса HTTP POST. При этом в зависимости от заголовка Transfer-Encoding определяется, читать ли данные в чанковом формате или на основе Content-Length. Согласно результатам сравнения графов потока управления, есть две модификации кода:

При парсинге чанкового формата вызывается ap_getline для чтения длины чанка и проверяется, не превышает ли возвращаемое значение ap_getline 16. Если больше 16, длина чанка считается недопустимой.

При чтении трейлера чанка источником записи \r\n является присвоение line_off. До исправления значение line_off бралось из *(_QWORD *)(a1 + 744), после исправления — из возвращаемого значения ap_getline.

Продолжая трассировку, можно обнаружить, что значение *(_QWORD *)(a1 + 744) — это длина поля длины чанка при первой проверке.

Продолжая трассировку, можно обнаружить, что значение *(_QWORD *)(a1 + 744) — это длина поля длины чанка при первой проверке.

В то же время, читая код, можно сказать, что когда значение поля длины чанка после hex-декодирования равно 0, выполнение переходит к логике чтения трейлера чанка.

Срабатывание выхода за границы

После анализа исправления можно сделать следующие выводы:

1. При парсинге чанка, если hex-декодированное значение поля длины чанка равно 0, начинается чтение трейлера чанка.
2. После вызова ap_getline для чтения трейлера чанка в буфер будет записано \r\n в соответствии с длиной поля длины чанка.

Следовательно, если в поле длины чанка передано много нулей, и длина нулей превышает 1/2 оставшейся длины буфера, будет спровоцирована запись \r\n за границы. Через отладку можно узнать, что целевой буфер находится на стеке (функция sub_1A111E0), и адрес возврата хранится по смещению 0x2028. Если по смещению 0x202e записано \r\n, то при возврате функция попытается выполнить инструкцию восстановления rip и произойдет сбой из-за недопустимого адреса.

Crash PoC:

Сценарий сбоя:

Анализируя причину уязвимости, видно, что она позволяет записать два байта \r\n за границы на стеке, и диапазон выхода близок к 0x2000. Поскольку записываемое содержимое очень ограничено, RCE не может быть достигнуто прямым перехватом rip. Поэтому необходимо сосредоточиться на указателях памяти, сохраненных в стеке.

неудачная попытка

Что приходит в голову, так это перехватить rbp и перезаписать младший байт rbp так, чтобы rbp указывал на управляемую область памяти. Когда родительская функция вернется к выполнению инструкции, rip можно будет полностью захватить. Однако при проверке было обнаружено, что даже если rbp в стеке перезаписан, rsp и rip не могут быть захвачены, и программа даже не вылетает. Продолжая трассировку вверх, находим родительскую функцию sub_1A111E0. Эта функция при возврате не вызывает leave ret для восстановления rsp, а напрямую add rsp, 0x18, поэтому ожидаемого эффекта достичь не удается.

Ищем другую точку проникновения

Как показано в предыдущем разделе, функция sub_1A26040 сохраняет значения пяти регистров rbx и r12-r15 в стеке и восстанавливает их при возврате. Продолжая обратную трассировку, находим родительскую функцию sub_1A27650. Видно, что в r13 сохраняется именно параметр a1.

a1 — это указатель на структуру. Через отладку также видно, что в стеке r13 сохраняется адрес кучи.

Если память в красной области на рисунке будет перезаписана записью за границы, то при восстановлении регистра r13 при возврате функции значение указателя может быть подделано. Если можно организовать кучу так, чтобы a1 указывал на заранее подготовленную область памяти, то вся структура a1 может быть захвачена. В то же время, анализируя код логики sub_1A27650 и sub_1A26040, можно обнаружить большое количество динамических вызовов членов многоуровневых структур a1, поэтому появится больше возможностей для захвата a1.

Захват структуры

В соответствии с предположением, после перезаписи младшего байта указателя a1 \r\n, он может указывать на предварительно организованную память. Как показано на рисунке:

Для достижения этого эффекта необходимо выполнить следующие условия:

• Адрес структуры a1 выше, чем адрес области heap spray, и разрыв между ними очень мал.
• 0x7fxxxxxxx0a0d должна указывать на поддельную структуру.

Отладка показывает, что размер структуры a1 равен 0x730. Согласно правилам выравнивания jemalloc, будет выделен блок кучи размером 0x800. Блоки кучи размером 0x800 не часто используются при обработке запросов, поэтому легко исчерпать блоки 0x800 в tcache и одновременно запросить больше новых блоков 0x800, так что после освобождения они попадут в tcache. Heap spray также выбирает блоки кучи нестандартного размера, чтобы новые запрошенные блоки были непрерывными и близкими к новым блокам 0x800; heap spray использует большие блоки кучи, чтобы гарантировать, что их адреса выровнены по 0x800, что позволяет легко гарантировать, что младшие 12 бит каждого поддельного адреса структуры равны 0xa0d; диапазон heap spray не меньше 0x10000, чтобы гарантировать, что адрес попадает в область heap spray. Эффект после захвата выглядит следующим образом: 0x7fxxxxxxx0a0d

Поиск эксплуатируемых многоуровневых указателей

С помощью вышеуказанных операций можно захватить структуру a1. Анализируя код функций sub_1A27650 и sub_1A26040, можно обнаружить множество динамических вызовов указателей второго и третьего уровней членов структуры a1, например:

Когда выполняется условие (0<N<5), будет динамически вызываться *(__int64 (__fastcall **)(__int64))(*(_QWORD *)(*(_QWORD *)(a1 + 0x298)+0x70)+0xC0)(a1). Таким образом, член a1 + 0x298 необходимо подделать в многоуровневый указатель, который в конечном итоге будет указывать на нужную нам функцию. Поскольку целевой бинарный файл не включает защиту PIE, можно найти подходящие многоуровневые указатели в целевом бинарном файле. Анализ бинарного файла показывает, что первый уровень указывает на адрес GOT-таблицы соответствующей функции. *(_BYTE *)(a1+0x20*(N+6)+0x10)&6==0

Таким образом, на примере функций можно найти подходящие многоуровневые указатели. system

Во время heap spray, изменив значение по смещению 0x298 структуры на 0x4368d0, можно использовать функцию system. Эффект выглядит следующим образом:

Как показано на рисунке, параметром динамического вызова является a1, а память, на которую он указывает, управляема. На этом этапе можно использовать функцию system для выполнения любой команды. Однако в FortiGate файл /bin/sh не имеет возможности выполнять команды, поэтому использование функции system для выполнения команд не увенчается успехом.

Захват RIP

Поскольку функция system не может выполнять команды, нужно найти другой способ для завершения RCE. Существующее условие: можно вызвать любую функцию из GOT-таблицы, и память, на которую указывает первый параметр функции, управляема. Таким образом, если в GOT-таблице есть функция, которая будет вызывать обратный вызов какого-либо члена параметра, есть шанс захватить RIP. Легко вспомнить функции, которые часто использовались в предыдущих эксплойтах для FortiGate. SSL_do_handshake

Нужно только сконструировать структуру SSL так, чтобы условия были выполнены, и финальный вызов s->handshake_func(s) привел к захвату rip. Перехватить rip на 0xdeadbeef, как показано на рисунке:

Главная программа FortiGate представляет собой бинарный файл All-in-One размером более 70 МБ. В нем содержится большое количество гаджетов, которые можно использовать. Реализовать RCE с помощью ROP несложно, поэтому не будем вдаваться в подробности.

демо:

Хотя веб-режим отключен по умолчанию в SSL VPN версии 7.4.2 и браузерный доступ возвращает 403, эта уязвимость все еще может быть использована в конфигурации по умолчанию.

Эта уязвимость похожа на уязвимость переполнения кучи, вызванную XOR, в прошлом году (CVE-2023-27997). Обе они представляют собой, казалось бы, бесполезные уязвимости переполнения. Процесс эксплуатации более хитрый и больше похож на задачу CTF. Однако по сравнению с традиционными CTF-задачами, атакующими менеджеры кучи, реальные уязвимости требуют больше контекстных структур и кодовой логики для эксплуатации. Уровень автора ограничен. Если есть ошибки, пожалуйста, поправьте меня.

Оригинальная статья на китайском: https://mp.weixin.qq.com/s?__biz=Mzk0OTU2ODQ4Mw==&mid=2247484811&idx=1&sn=2e0407a32ba0c2925d6d857f4cdf7cbb&chksm=c3571307f4209a110d6b28cea9fe59ac0f0a2079c998a682e919860f397ea647fa0794933906&mpshare=1&scene=1&srcid=0313EaETjGzEAvOdByUt6ovU#rd