Отказ от ответственности

Честно говоря, я не знаю, как он додумался найти эту уязвимость. Поэтому я не могу полностью её объяснить. Но я постараюсь сделать всё возможное, чтобы рассказать всё, что я понял об этой CVE.

Уязвимость

Эта CVE довольно интересна, потому что в ней две уязвимости: LFD раскрытие локальных файлов и RCE удалённое выполнение кода. Классно! Итак, в этом посте я объясню обе уязвимости этой CVE.

Раскрытие локальных файлов (используйте docker-образ no-cgi)

Итак, начнём с уязвимости раскрытия локальных файлов. Если вы знакомы с apache, вы можете заметить, что cgi-bin (Common Gateway Interface) — это путь по умолчанию, который определяет способ взаимодействия веб-сервера с внешними программами, генерирующими контент, в apache-2.4.49.

Но этот путь Forbidden для всех и даже для администратора. Хм, это интересно, правда?

И если вы знакомы с уязвимостью раскрытия локальных файлов, вы, вероятно, знаете, что большинство уязвимостей LFD происходит именно в запрещённых путях.

Итак, давайте протестируем простые LFI-пейлоады в пути /cgi-bin/.

Я поставил ../../../../../ перед /etc/paswd. (Если вы хотите узнать, что такое ../, прочтите эту статью в блоге: Обход раскрытия локальных файлов)

С помощью curl:

С помощью burpsuite:

Как вы можете видеть, с этим простым пейлоадом мы получили ошибку. В curl мы получили код состояния 404 — ошибку Not Found, а в Burp — ошибку 400 Bad Request.

Это означает, что нам нужно закодировать наш пейлоад в URL-кодировку. Давайте попробуем и посмотрим, что у нас получится.

Итак, я закодировал . в Url. Примечание: . — это %2E, а также %2e в url-кодировке.

С помощью curl:

С помощью Burp:

Да! Наш пейлоад сработал. Мы можем прочитать /etc/passwd сайта.

Итак, надеюсь, теперь вы поняли уязвимость LFD этой CVE. Давайте перейдём к уязвимости RCE этой CVE для apache 2.4.49.

Удалённое выполнение кода (используйте docker-образ with-cgi)

Чтобы объяснить уязвимость RCE этой CVE, вам нужно понять некоторые основы RCE и основы linux.

Прочтите эту статью в блоге, чтобы узнать: Что такое RCE

Ах, думаю, вы подумали, что я оговорился, сказав, что нужны основы linux. Нет. Я не ошибся, потому что они нам действительно нужны. Итак, начнём!

Сначала позвольте мне показать рабочий пейлоад, и я объясню, как он работает.

С помощью Curl:

Объяснение пейлоада

Итак, позвольте мне объяснить этот пейлоад.

Как вы можете видеть, путь /cgi-bin/ и кодировка .%2e такие же. Но теперь есть ещё две опции: -d данные и /bin/sh /bin/bash. Итак, позвольте мне объяснить, почему нам нужно их использовать.

/Bin/Bash

Во-первых, мы хотим получить удалённое выполнение кода, верно?

Как вы знаете, в системах на базе linux /bin/bash — это основной компонент для выполнения и ввода команд и работы с оболочками. Поэтому нам нужен bash, чтобы выполнять наши команды на веб-сервере. Почитайте об этом: Что такое Bash в linux.

Данные

Хорошо, теперь предположим, что мы можем получить /bin/sh. Нам остаётся только внедрить наши команды. Мы можем отправить нашу инъекцию как данные с помощью curl.

Итак, наш пейлоад — C|echo;id. Позвольте мне объяснить, что это такое.

Итак, C ничего не значит. Мы можем поставить что угодно перед |. Например, Comdey|.

echo;id — это просто трюк с linux. Итак, я говорил, что нужны основы linux. Основы Echo

Если мы сложим всё это вместе, мы получим RCE в apache 2.4.49.

Спасибо!

Спасибо за чтение, ребята! Это мой первый врайтап по CVE. Простите, если я плохо объяснил. И, пожалуйста, дайте мне свои предложения.