Дневник белой шляпы [Часть 5]: Удачная догадка [RCE - Проверка простейших CVE, найденных в PHP-приложениях]

[D2]

<?php (Вступление)

Эта статья об одном из моих первых вознаграждений и моем первом RCE. Как вы, возможно, знаете из первой части моего дневника, после сообщения о том, как компания подверглась DDoS-атаке, они использовали меня в качестве пентестера. На этот раз я нашел RCE в их системе очень известным и простым способом.

Я не хочу быть похожим на большинство статей RCE, поэтому мы проверим некоторые CVE и попытаемся их понять. Я не собираюсь анализировать известные CVE, которые, вероятно, сам не пойму. Мы проверим простые случаи.

Ребята, которые просили SQLi, не расстраивайтесь, у меня есть несколько случаев с этим, но я хочу объяснить NoSQL в хорошей манере, я все еще думаю об этом, вот почему я разместил RCE вместо SQLi
Уровень: Легкий
Предварительные требования: Базовые знания веба, базовые знания Linux, понимание того, что такое CVE, и знание английского языка (для понимания процесса исправления)

Содержание

1. История
2. Что такое RCE?
3. Лаборатория № 1 (Понимание RCE)
4. Примеры CVE
5. Мой случай

История
Я был новичком в этой области (ничего не изменилось) и получил RCE в CTF, когда был стажером. Итак, однажды, как обычно, я проверял веб-сайт и увидел загруженный файл (типичное место проведения гонок), попытал удачу, и это сработало. Я объясню более подробно, объясняя уязвимость. Этот случай прост, но я нигде не видел подобного случая.

Также стоит упомянуть, что однажды в интервью мне задали вопрос об устранении уязвимости RCE. Это было интервью для Junior AppSec, думаю, им понравился мой ответ, после него в зале воцарилась тишина. Они звонили мне 3 раза за 3 месяца, сообщая, что меня приняли, и извиняясь за быстроту действий. В результате меня не приняли, но я счастлив, потому что я тоже сказал им, что все, чего я хочу, - это опыт, и собеседование было очень хорошим, так как интервьюеры были профессионалами. Главное - это тот факт, что я прошел собеседование. Я думаю, причина, по которой меня не приняли, заключается в том, что я могу работать только неполный рабочий день.

Я люблю интервью, когда вопросы "основаны на конкретных примерах", я могу ответить лучше, в противном случае вопрос "Что такое RCE?" - это не вопрос.


Что такое RCE?

RCE (Remote Code Execution) - Удаленное выполнение кода - позволяет нам выполнять код на сервере-жертве. Пожалуйста, поймите, что код и команда - это разные вещи. Например, код написан на одном из языков программирования, в то время как command - это команда операционной системы. Выполнить команду можно с помощью кода (это означает, что, используя код, написанный на языке программирования, мы можем выполнить команду операционной системы). Позвольте мне привести вам 2 примера.

Это PHP-код, выполняющий команду "whoami"
PHP: Скопировать в буфер обмена
<?php system("whoami")?>

Это команда "whoami".
Bash: Скопировать в буфер обмена
whoami

Это все, что вам нужно знать на данный момент, я объясню методы, которые я знаю в лаборатории.

Лаборатория № 1

Ссылка: https://portswigger[точка]net/web-security/file-upload/lab-file-upload-remote-code-execution-via-web-shell-upload

Я не читал описание лаборатории, но сделаю это, если самостоятельно не добьюсь никакого результата. Сначала мы должны войти в систему, каждый логин в portswigger labs - это wiener:peter.

Это наша учетная запись после того, как мы войдем в систему. Он состоит из 2 частей: обновление электронной почты и загрузка аватара. Любой, у кого есть хоть какой-то опыт, понимает, что уязвимость, вероятно, находится в части "загрузка аватара", но давайте подумаем, что уязвимость есть в обеих частях.

Ну, а как получилось, что обновление электронной почты может быть использовано RCE? Я не говорю, что это так, но давайте подумаем, что это так, каковы были бы случаи?

1. Запрос обновления SQL в функции обновления электронной почты SQL-инъекция может привести к RCE.
2. Если используется определенный шаблон (Template Injection), то при вводе кода шаблона может возникнуть RCE.
3. Если входные данные не обработаны должным образом, внедрение кода (например, php-кода) может привести к внедрению кода (вероятно, слепому) (звучит глупо, да?).

Ну, это не относится к части электронной почты) Но все же приятно думать, что это для того, чтобы понять, что бы вы сделали в этой части. Главная цель лаборатории - не решить ее, а узнать что-то новое.

Изображение [1]: Мой аккаунт​

Что такое изображение? Формат png, jpeg... файлы. Вы когда-нибудь думали о том, чтобы загрузить текстовый файл вместо изображения? Как новичок, я помню, что сначала это поразило меня, и я снова разозлился на себя за то, что это не пришло мне в голову, теперь я понимаю, что это "видение / vision", и оно приходит со временем, у каждого оно есть в какой-то области, им просто нужно его открыть и расширить.

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

Итак, я загрузил изображение

Изображение [2]: Загрузка изображения​

Теперь давайте разберемся с загруженной полезной нагрузкой (payload) . Данные отправляются в виде нескольких частей, изображение отправляется не как полезная нагрузка в кодировке base64, оно является необработанным. Мы можем видеть ÿØÿà и JFIF. Итак, что же все это означает на языке пришельцев? Эти инопланетные символы называются магическими байтами. Магические байты используются для определения типа файла. Обычно мы определяем тип файла по расширению файла, например, если файл заканчивается на .jpg, мы говорим, что это изображение, и Windows откроет его как imag, но что, если кто-то просто отредактировал текстовый файл и заменил расширение .txt на .jpg? В этом случае Windows попытается открыть его как образ (большинство дистрибутивов Linux этого не делают). Очевидно, что каждый может редактировать как расширения, так и магические байты, но все же оба они используются для определения типа файла.

Вы можете просмотреть список магических байтов по этой ссылке: https://en.wikipedia[точка]org/wiki/List_of_file_signatures

Волшебный байт	Описание
ÿØÿà␀␐JFIF␀␁	Cырой JPEG или в формате файла JFIF или Exif

Если вы любитель интерфейса командной строки, вы можете установить "whatweb", чтобы получить технологии, используемые веб-приложением. Я просто буду использовать расширение "wappalyzer".

Технологии необходимы для понимания того, как, возможно, написано веб-приложение (они не точны на 100%), это поможет использовать для внедрения кода. Представьте себе веб-приложение с бэкендом, написанным на Java, и мы пытаемся внедрить PHP-код, насколько это хорошая идея?

Ссылка на расширение для firefox: https://addons.mozilla[точка]org/en-US/firefox/addon/wappalyzer/

Давайте откроем каталог, в котором было сохранено наше изображение.

Изображение [3]: Открытие изображения

Изображение [4]: Открытие изображения​

Wappalyzer не выдал никаких результатов об используемых языках программирования, если мы проверим описание лаборатории, то увидим, что нам нужно загрузить базовую оболочку (shell) PHP.

Давайте создадим файл xss.php и добавим этот код:

PHP: Скопировать в буфер обмена
<?php system("id"); ?>

Он попытается выполнить команду "id". Кстати, мы знаем, что сервер, который использует веб-сайт, - это ubuntu, wappalyzer показал нам =)

Изображение [5]: Wappalyzer

Изображение [6]: Загрузка xss.php

Изображение [7]: Открытие xss.php​

Это простой случай, но системы уязвимы к нему. Мы можем использовать простую веб-оболочку PHP выполнения команд непосредственно через передачу входных данных по ссылке. Мы можем использовать этот код для этого:
PHP: Скопировать в буфер обмена
<?php system($_GET['xss']);?>

Изображение [8]: Загрузка xss.php​

Если вы обратите внимание, наш код имеет $_GET['xss'], это означает, что мы отправим запрос GET с параметром xss.

Изображение [9]: Выполнение команды с помощью xss.php​

Целью этой лабораторной работы было чтение файла /home/carlos/secret. Я выполнил эту команду whoami; cat /home/carlos/secret. Команда была выполнена простым открытием ссылки https://XXXXXXXXXXXXXXXXX.web-security-academy.net/files/avatars/xss.php?xss=whoami; cat /home/carlos/secret

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

1. Запретить PHP выполнять код типа "system()"
2. Запретить загрузку файлов с определенными расширениями.
3. Запретить загрузку файлов с определенными магическими байтами.
4. Сделать все загруженные файлы неисполняемыми (лучший вариант).

О первом исправлении
Я был стажером, и у меня была задача найти уязвимости, я нашел уязвимость при загрузке файла, но не смог выполнить "system()", поэтому я запустил этот код, чтобы понять список уязвимых функций PHP, которые я могу выполнить:
PHP: Скопировать в буфер обмена
<?php print_r(preg_grep("/^(system|exec|shell_exec|passthru|proc_open|popen|curl_exec|curl_multi_exec|parse_ini_file|show_source)$/", get_defined_functions(TRUE)["internal"])); ?>

О втором исправлении
Ну, допустим, система запрещает загрузку php-файлов, злоумышленник все равно сможет загрузить .php, .php2, .php3, .php4, .php5, .php6, .php7, .phps, .pht, .phtm, .phtml, .pgif, .shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module.
Решит ли проблему предотвращение загрузки всех этих расширений? Это не решит проблему, но снизит вероятность возникновения проблемы в первую очередь. Существует несколько способов обойти внесение расширений в "черный список".

Например, было бы лучше разрешить загрузку только файлов .jpg, это называется "белый список", и его сложнее обойти.

О третьем исправлении
Магическими байтами можно манипулировать, пользователь может загрузить файл .php с магическим байтом, начинающимся как GIF87a; и система будет думать, что это GIF-файл, а не PHP. Это очень известная методика обхода.

О четвертом исправлении
Пока он правильно настроен, это лучший вариант, который я вижу, чтобы предотвратить чрезмерный RCE. Но и здесь есть проблема, вопрос в том, будет ли разработчик препятствовать выполнению всех загруженных файлов в определенном каталоге или во всех каталогах? Если существует уязвимость при включении файла, можно будет заменить имя загруженного файла на ../xss.php например, и он загрузит один каталог сверху. Что тогда произойдет?

Домашнее задание: Попробуйте полезную нагрузку (payload / code), которая показывает список опасных функций PHP в лаборатории.

Примеры CVE

Пришло время проверить несколько простых CVE!

Первый: https://huntr[точка]dev/bounties/0bd5da2f-0e29-47ce-90f3-06518656bfd6/

Я даже не собираюсь проверять скриншоты и видео, загруженные исследователем, я погружусь в процесс исправления.

Исправление: https://github[точка]com/cockpit-hq/cockpit/commit/800c05f1984db291769ffa5fdfb1d3e50968e95b

PHP: Скопировать в буфер обмена

                $_sizeAllowed = $max_size ? filesize($files['tmp_name'][$i]) < $max_size : true;

                // prevent uploading php files
//Удаленo                if ($_isAllowed && in_array(strtolower(pathinfo($_file, PATHINFO_EXTENSION)), ['php', 'phar', 'phtml'])) {
                if ($_isAllowed && in_array(strtolower(pathinfo($_file, PATHINFO_EXTENSION)), ['php', 'phar', 'phtml', 'phps'])) {
                    $_isAllowed = false;
                }

Итак, разработчик выполнил второе исправление, о котором я говорил выше, добавив расширения в черные списки, но, как вы видите, оно неполное. (Я НЕ НАРУШАЮ НИКАКОГО ЗАКОНА, ПОСКОЛЬКУ В ОБНОВЛЕННОМ КОДЕ НЕТ ТАКОЙ УЯЗВИМОСТИ)

Второй: https://huntr[точка]dev/bounties/71fe4b3b-20ac-448c-8191-7b99d7ffaf55/
Исправление: https://github[точка]com/microweber/microweber/commit/93a906d0bf096c3ab1674012a90c88d101e76c8d

PHP: Скопировать в буфер обмена

            array_walk_recursive($input, function (&$input) use ($clean) {
                if (is_string($input)) {
                    $input = $clean->clean($input);
                    // clean also blade curly braces
                    $input = str_replace(['{{', '}}'], ['{{', '}}'], $input);
                }
            });
        }

В данном случае мы видим, что разработчик пытается html закодировать скобки, в то же время это используется для предотвращения XSS. Но почему скобки приводят к RCE? Ну, эта атака называется SSTI (внедрение шаблона на стороне сервера). Я объясню это вкратце. Некоторые разработчики используют готовые шаблоны, чтобы упростить свою работу при создании веб-сайтов. Эти шаблоны, очевидно, основаны на каком-то языке программирования, и у них есть свои собственные коды. Можно злоупотреблять этими кодами и выполнять команды, иногда это может привести к RCE.

Кодировка HTML - хорошая идея, и обойти ее сложно, но важно делать это во всех местах, где пользователь может вводить данные. Очевидно, что возникают вопросы типа "Как сервер будет обрабатывать url-кодированные скобки?" "Как сервер будет обрабатывать двойные url-кодированные скобки?" "Как сервер будет обрабатывать уже html-кодированные скобки?"

Я не знаю и не могу ответить на эти вопросы из-за недостатка опыта, но в будущем, я уверен, будет статья об этом, написанная мной =)

Третий: https://huntr[точка]dev/bounties/3dab0466-c35d-4163-b3c7-a8666e2f7d95/
Исправление: https://github[точка]com/flatpressblog/flatpress/commit/c30d52b28483e1e512d0d81758d4c149f02b4068
Я расскажу вам, что, как мне кажется, я понял из этого, я уверен, что более опытные люди, читающие это, помогут. Проверяя все это, я не использую GPT, так как это может дать false positive (вероятно, так и будет).

Очевидно, я могу ошибаться.

Исследователь сказал, что уязвимость находится здесь: admin.php?p=uploader&action=default. Это означает, что мы должны найти эту часть кода.

Изображение [10]: Фиксация на Github​

Если вы нажмете на кнопку развернуть, то увидите список расширений, занесенных в черный список.

PHP: Скопировать в буфер обмена

         *
         * 2019-11-23 - laborix
         */
        $blacklist_extensions = array(
            'htaccess',
            'phtml',
            'php',
            'php3',
            'php4',
            'php5',
            'php6',
            'php7',
            'phps',
            'cgi',
            'exe',
            'pl',
            'asp',
            'aspx',
            'shtml',
            'shtm',
            'fcgi',
            'fpl',
            'jsp',
            'htm',
            'html',
            'wml'
        );
        $imgs = array(
            '.jpg',
            '.gif',
            '.png',
            '.jpeg'
        );
        // intentionally
        // I've not put BMPs
        $uploaded_files = array();
        $this->smarty->assign('uploaded_files', $uploaded_files);

Разработчик внес в черный список большинство расширений и только изображения в белом списке. Комментарии помогут нам понять, что пытался сделать разработчик. Разработчик пытался предотвратить использование двойных расширений. Это когда вы используете .jpg.php чтобы злоупотреблять системой.

PHP: Скопировать в буфер обмена

                $check_ext1 = "";
                $check_ext2 = "";
                $check_ext1 = trim($deeptest [$extcount - 1], "\x00..\x1F");
                if (in_array($check_ext1, $blacklist_extensions)) {
                    $isForbidden = true;
                } else {
                    $isForbidden = false;
                }
                /* Test only if first extension check are not in the blacklist */
                if (!$isForbidden) {
                    $check_ext2 = trim($deeptest [$extcount - 2], "\x00..\x1F");
                    if (in_array($check_ext2, $blacklist_extensions)) {
                        $isForbidden = true;
                    } else {
                        $isForbidden = false;
                    }
                }
            }
            /*
             * If one blacklisted extension found then
             * return with -1 = An error occurred while trying to upload.
             */
            if ($isForbidden) {
                $this->smarty->assign('success', $success ? 1 : -1);
                sess_add('admin_uploader_files', $uploaded_files);
                return -1;
            }

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

Я не разбираюсь в разработке, но все же интересно, что произойдет, если пользователь попытается присвоить файлу имя .php.jpg.jpg

PHP: Скопировать в буфер обмена

            /*
             * third check extension
             * if someone upload a .php file as .gif, .jpg or .txt
             * if someone upload a .html file as .gif, .jpg or .txt
             *
             * 2019-11-24 - laborix
             */

            if (version_compare(PHP_VERSION, '5.3.0') < 0)
                return -1;
            if (!function_exists('finfo_open'))
                return -1;

            $finfo = finfo_open(FILEINFO_MIME_TYPE);
            $mime = finfo_file($finfo, $tmp_name);
            finfo_close($finfo);

            if (($mime == "text/x-php") || ($mime == "text/html")) {
                $this->smarty->assign('success', $success ? 1 : -1);
                sess_add('admin_uploader_files', $uploaded_files);
                return -1;
            }

Эта часть посвящена magic byte, на случай, если пользователь злоупотребляет использованием magic bytes, используя "GIF87a;" в начале файла, а также проверяет тип содержимого загруженного файла. Опять же, я могу ошибаться.

Кстати, проверка заголовка "Content-Type" - это один из способов определить, какой файл пользователь пытается загрузить. И может быть использован для предотвращения RCE. Очевидно, что этим тоже можно манипулировать.

Мой случай

В моем случае была уязвимость при загрузке файла. Это была часть веб-сайта для загрузки gif-изображений, и эти изображения будут отправлены в ваш социальный профиль в виде файла. Я использовал этот код:

PHP: Скопировать в буфер обмена

GIF87a;
<?php system("ls"); ?>

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

Автор grozdniyandy​

Источник https://xss.is/​